La Fibre
Fournisseurs d'accès à Internet fixe en France métropolitaine => SFR / RED => 
Actus SFR Altice => Discussion démarrée par: VincentAlex le 06 avril 2016 à 08:02:18
-
[Titre original : « IPv6-only et MAP-T ? »]
Bonjour,
J'aimerai savoir si derrière ces noms de technologie il ne se cacherai pas la même possibilité de Free de partager les adresses IPv4 entre plusieurs abonné.
Merci
-
Tu fais référence à cette page du firmware en bêta test ?
(https://lafibre.info/images/altice/201604_firmware_sfr__ipv4_cgnat.png)
-
le 4rd utilisé par Free en ZMD est une sorte de MAP-T amélioré.
voir: https://en.m.wikipedia.org/wiki/IPv4_Residual_Deployment
-
Tu fais référence à cette page du firmware en bêta test ?
(https://i.imgur.com/4B7w0be.png) (https://lafibre.info/sfr-les-news/ipv6-only-et-map-t/?action=dlattach;attach=24369;image)
(https://i.imgur.com/L8SVvzW.png)
MAP-T est bien une des multiples ramifications dans lesquelles est partie la norme 4rd, les principales différences avec les autres (MAP-E et 4rd) portant sur la manière dont les trames sont encapsulées/translatées et la gestion de la fragmentation, comme expliqué ici : https://en.wikipedia.org/wiki/IPv4_Residual_Deployment#History mais MAP-T implique effectivement un support de A+P, lui aussi (et ce screenshot laisse peu de doute).
Je pourrais connaître la version de firmware ?
-
3.5.1 (beta test devant conduire à l'ipv6 natif sur le réseau SFR )
-
Tous les détails techniques suite à un rapide survol du firmware :
Le script /etc/init.d/mapt qui s'occupe de la configuration :
#!/bin/sh /etc/rc.common
service=mapt
logger -t "${service}[$$]" "$action"
[...]
start() {
local control="/proc/net/nat46/control"
local ifname="$(status get net_mapt_ifname)"
local ifnamev6="$(status get net_ipv6_ifname)"
local localv4="$(status get net_mapt_bmr_prefixv4)/$(status get net_mapt_bmr_maskv4)"
local localv6="$(status get net_ipv6_prefix)"
local remotev6="$(status get net_mapt_dmr_prefixv6)/$(status get net_mapt_dmr_maskv6)"
local ealen="$(status get net_mapt_ealen)"
local offset="$(status get net_mapt_offset)"
local ip6addr="$(status get net_mapt_ip6addr)"
local ipaddr="$(status get net_mapt_ipaddr)"
local ipmask="$(status get net_mapt_bmr_maskv4)"
local portsets="$(status get net_mapt_portsets)"
local mapt_subnet="$(status get net_ipv6_prefix | sed s:/56:/64:)"
echo add ${ifname} > ${control}
echo config ${ifname} local.style MAP local.v4 ${localv4} \
local.v6 ${localv6} local.ea-len ${ealen} \
local.psid-offset ${offset} remote.v4 0.0.0.0/0 \
remote.v6 ${remotev6} remote.style RFC6052 \
remote.ea-len 0 remote.psid-offset 0 > ${control}
ip -6 address add ${ip6addr} dev ${ifname}
ip address add ${ipaddr}/${ipmask} dev ${ifname}
ip route delete local ${ip6addr} via :: dev lo
echo ${portsets} | sed "s/-/ /g" > /proc/sys/net/ipv4/port_ranges
# only one range is required for icmp
local range=$(echo ${portsets} | sed "s/ .*//")
# ipv4 SNAT
iptables -t nat -F POSTROUTING
iptables -t nat -A POSTROUTING -p icmp -o ${ifname} \
-j SNAT --to-source ${ipaddr}:${range}
iptables -t nat -A POSTROUTING -p tcp -o ${ifname} \
-j SNAT --to-source ${ipaddr} --random
iptables -t nat -A POSTROUTING -p udp -o ${ifname} \
-j SNAT --to-source ${ipaddr} --random
# user nat
iptables -t nat -F PREROUTING
iptables -t nat -A PREROUTING -d ${ipaddr} -j USER_NAT
iptables -t nat -A PREROUTING -d ${ipaddr} -j MINIUPNPD
/etc/init.d/nat user_nat
xtables -F MAPT_FILTER
xtables -D FORWARD -j MAPT_FILTER
xtables -A FORWARD -j MAPT_FILTER
# ipv6 forward
ip6tables -A MAPT_FILTER -i ${ifname} -s ${mapt_subnet} \
-o ${ifnamev6} -d ${remotev6} -j ACCEPT
ip6tables -A MAPT_FILTER -o ${ifname} -d ${mapt_subnet} \
-i ${ifnamev6} -s ${remotev6} -j ACCEPT
# ipv4 forward
iptables -A MAPT_FILTER -o ${ifname} -m state --state INVALID -j DROP
iptables -A MAPT_FILTER -i ${ifname} -m state --state NEW -j WIN_FILTER
iptables -A MAPT_FILTER -o ${ifname} -m state --state NEW -j WIN_FILTER
iptables -A MAPT_FILTER -o ${ifname} -p tcp -m tcp --dport 25 -j SMTP_FILTER
# use mapt0 as default ipv4 route
ifconfig ${ifname} up
ip route delete default
ip route add default dev ${ifname}
ip route delete default table lan_t
ip route add default dev ${ifname} table lan_t
# update status
status set net_mapt_status up
/etc/init.d/nat algs
diaglog event mapt
event notify mapt-up
}
stop() {
local control="/proc/net/nat46/control"
local ifname="$(status get net_mapt_ifname)"
# cleanup firewall
iptables -t nat -F POSTROUTING
iptables -t nat -F PREROUTING
xtables -F MAPT_FILTER
xtables -D FORWARD -j MAPT_FILTER
# clean up mapt iface
ifconfig ${ifname} down
echo del ${ifname} > ${control}
# update status
status set net_mapt_status down
/etc/init.d/nat algs
event notify mapt-down
}
Les diverses variables présentes au début du script sont poussées par le système de configuration maison (HTTP/XML récupéré périodiquement) de SFR.
Le module standard d'OpenWRT pour faire la partie translation d'adresses de MAP-T, appelé NAT46 (https://github.com/ayourtch/nat46), est utilisé. Netfilter s'occupe de randomiser proprement les ports des connexions sortantes.
L'interface web a bien été adaptée pour restreindre la redirection de ports aux ports autorisés, avec des messages de type : "Cette plage de ports est indisponible en IP".
Pour les plus curieux, l'image est à télécharger ici http://ncdn.nb4dsl.neufbox.neuf.fr/nb6_Version 3.5.1/NB6-MAIN-R3.5.1 (http://ncdn.nb4dsl.neufbox.neuf.fr/nb6_Version 3.5.1/NB6-MAIN-R3.5.1) (à extraire avec binwalk).
-
Tu fais référence à cette page du firmware en bêta test ?
C'est bien par rapport à ça.
Merci pour vos réponses qui sont toujours très détaillée.
-
Voilà un sujet intéressant à suivre.
-
Quelle horreur ce truc ::)
Ils peuvent pas juste nous mettre l'IPv6 natif, faut une contrepartie...
Ça doit leur faire des IPv4 à revendre tant que ça vaut quelque chose, qu'on me fasse pas croire à un manque d'IP avec tous les clients qui se sont barrés.
-
Quelle horreur ce truc ::)
Ils peuvent pas juste nous mettre l'IPv6 natif, faut une contrepartie...
ça tu l'aura :) (IPv6-Only)
-
Quelle horreur ce truc ::)
Ils peuvent pas juste nous mettre l'IPv6 natif, faut une contrepartie...
Ça doit leur faire des IPv4 à revendre tant que ça vaut quelque chose, qu'on me fasse pas croire à un manque d'IP avec tous les clients qui se sont barrés.
Il y a très peu de client qui sont partis sur le fixe... l'hémorragie a été sur le mobile. (et il faut "donner" des ips à Numéricable puisque SFR migre ses clients dessus).
Après, je ne sais pas comment SFR attribue ses IPs, si c'est par DSLAM / switch optique ou au niveau régional. (SFR propose un ip fixe sur la majorité des DSLAMs maintenant et fixe en FTTH.)
Et je pense que c'est décidé depuis un peu plus longtemps.
Après Drahi est présent dans plusieurs pays, il doit pouvoir bouger ses ipv4 d'un pays à l'autre (tant que çà reste dans le bon secteur RIPE).
-
Il y a très peu de client qui sont partis sur le fixe...
Justement, SFR peut très bien réutiliser des IPv4 mobile pour le fixe si le besoin s'en fait sentir. Après, comme c'est du CGNAT sur le mobile, il y a moins d'IP à récupérer, mais ça en fait toujours quelques-unes.
(et il faut "donner" des ips à Numéricable puisque SFR migre ses clients dessus).
Si un client NC a une IP SFR, il libère une IP NC. Car SFR a toujours les plages IP de NC (AS 21502). Donc donner une IP SFR à un client câble ne mangera pas une IP.
-
Il y a très peu de client qui sont partis sur le fixe... l'hémorragie a été sur le mobile. (et il faut "donner" des ips à Numéricable puisque SFR migre ses clients dessus).
Après, je ne sais pas comment SFR attribue ses IPs, si c'est par DSLAM / switch optique ou au niveau régional. (SFR propose un ip fixe sur la majorité des DSLAMs maintenant et fixe en FTTH.)
Et je pense que c'est décidé depuis un peu plus longtemps.
Après Drahi est présent dans plusieurs pays, il doit pouvoir bouger ses ipv4 d'un pays à l'autre (tant que çà reste dans le bon secteur RIPE).
Comme tu dis, "migre". Donc ça prendra pas plus d'IP à moyen terme.
Ça me fait mal de voir qu'il s'attaque à la seule partie qui tient debout chez SFR, à savoir le réseau fixe.
-
S'ils vous plaît, vous pouvez arrêter de répandre de la désinformation. Les adresses IP sont allouées de manière générale par plages à des équipements et non sur une base individuelle à des clients, et ce genre de transition n'est pas simple ni triviale. Vous ne connaissez clairement rien à votre sujet et il y a sûrement des utilisateurs peu techniques qui risquent de vous croire.
-
Il y avait eu le même débat pour Free.
Ouais, t'as peut être raison, le réseau de SFR est complexe. N'empêche que la transition vers le "MAP-T" ils arrivent bien à la mettre en place. Le résultat c'est que ça va être de la merde, on le sait de façon sure ça par contre.
-
Mieux vaut commencer - comme Free d'ailleurs - en 2016 pour espérer avoir un truc qui marchera quand ce sera nécessaire...
-
Le résultat c'est que ça va être de la merde, on le sait de façon sure ça par contre.
Pourquoi ce serai de la merde ?
-
Avoir une range de ports attribués limité si j'ai bien suivi le topic Free ?
-
Oui c'est ça, au lieu de recevoir une adresse ("A") tu vas avoir une adresse et des ports UDP et TCP (et SCTP?), c'est "A+P".
Et si tu avais besoin d'un port précis en dehors, ben tu l'as dans le baba - pour l'instant.
-
Sauf s'il y aura une option IPv4 dédiée.
-
Mais à quel prix?
-
Ça, mystère... Mais si c'est payant, ceux qui y tiennent vraiment payeront, comme l'option IP "vraiment" fixe chez Orange.
-
rani n'a pas laissé entendre sur ce forum que ce serait gratuit. Mais qu'une option pour avoir plus d'IPs (<3) pourrait être payante ?
-
Il a dit que l'option pour une IPv4 complète serait gratuite, mais que l'option pour plusieurs IPv4 serait payante, histoire que certains ne réservent pas de plages pour rien.
-
Ça, mystère... Mais si c'est payant, ceux qui y tiennent vraiment payeront, comme l'option IP "vraiment" fixe chez Orange.
Ceux de chez Orange qui y tiennent vraiment en xDSL vont ailleurs. M'enfin ceci-dit, Orange n'a toujours pas corrigé le bug du préfixe ipv6 variable en architecture DHCP, (si c'est bien un bug)
Sinon il faut se dire que le gain d'IPv4 est énorme en passant sur un partage, du moment que l'opérateur propose l'option IPv4 dédiée c'est un bon compromis comparativement aux gens qui n'ont pas besoin en majorité. Le seul problème c'est que si beaucoup d'abonnés suivent des tutos leur indiquant d'activer l'option IP dédiée en pensant que ça résoudrait un hypothétique problème qui n'a rien à voir, cela ferait du gaspillage pour rien.
-
rani n'a pas laissé entendre sur ce forum que ce serait gratuit. Mais qu'une option pour avoir plus d'IPs (<3) pourrait être payante ?
Rani :
La première sera gratuite, c'est certain. Après, ceux qui veulent une /29 ou truc du style, on
fera payer un minimum histoire que ceux qui le demandent en aient vraiment besoin.
https://lafibre.info/free-10g-epon/cgn-14-chez-free-une-ipv4-partagee-par-4-clients/msg307309/#msg307309
-
Pour moi il aurait été plus logique que ceux qui n'ont une pas une IP entière soient en IP non fixe, cela fournirait une incitation.
-
rani n'a pas laissé entendre sur ce forum que ce serait gratuit. Mais qu'une option pour avoir plus d'IPs (<3) pourrait être payante ?
Si l'on ne fait pas attention à ton point d'interrogation à la fin, on pourrait croire que ta première phrase est une affirmation.
J'ai failli répondre dans ce sens.
-
Si l'on ne fait pas attention à ton point d'interrogation à la fin, on pourrait croire que ta première phrase est une affirmation.
J'ai failli répondre dans ce sens.
Il faudrait une virgule ou mieux point virgule au milieu.
Je n'avais pas compris la phrase non plus.
-
Pourquoi ce serai de la merde ?
Parce qu'il ne sait sans doute pas de quoi il parle.
L'idée de MAP-T c'est d'une part de donner (enfin ! pourrait-t-on dire) aux abonnés une IPv6 native (donc pas du tunneling ou du NAT ou whatever) et si il y a nécessité de communiquer avec un service IPv4 only alors MAP-T permet de réaliser une translation d'adresse (en gros du NAT64 mais sans avoir à maintenir un état comme avec un NAT classique).
C'est donc plutôt élégant mais pas simple à mettre en oeuvre.
Par contre effectivement si un service externe IPv4 only souhaite communiquer vers la box de l'abonné ça peut être compliqué. Mais il faut savoir si on veut un jour ou non passer pour de vrai à l'IPv6. En tout cas ça n'est pas de la gestion de la pénurie d'IPv4
-
Depuis quelques temps j’ai le message comme quoi je suis en ip partagée.... et bizarrement depuis un moment j’ai du mal à accéder à mes caméras IP.
Comment connaître la plage IP que l’on m’a attribué ?
-
Ou apparaît le message "ip partagée" ?
Tu aurais une copie d'écran ?
-
(https://lafibre.info/images/altice/201711_sfr_ip_partagee.png)
-
Il me semble que c'est indiqué sur l'onglet NAT
-
L’onglet nat j’ai rien mais sur trace route comme on le voit sur l’imprime écran c’est stipulé
-
Hum, je pense à un bug du firmware (quelle est la version de ton firmware ?)
En fait, sur la page tests, ce warning est conditionné à l'état de IPv6 (IPv6 actif).
Or, sur la page nat v4, le warning relatif au nombre réduit de port est conditionné par l'état du mapt (mapt actif). Et si c'est le cas, c'est indiqué : "Attention, du fait de votre IPv4 partagée, vous ne disposez que d’un nombre limité de ports externes pour vos règles de NAT. La liste de ces ports est disponible via le bouton se trouvant à droite de la zone de saisie des ports externes."
ensuite, si tu cliques sur le petit bouton, une popup s'ouvre où la plage de port possible est indiquée.
Essaie de désactiver l'IPv6 pour voir ce que cela donne.
-
En supprimant ipv6 le message disparaît.
Ça me fait penser que les test ipv6 dispo sur le net sont en échec chez moi depuis que mes règles nat ne fonctionnent plus pour l’accès à mes caméras.
Et depuis j’apparais en ipv6 natif
Il y a un bug quelques part
-
Ici j'ai le même message alors que j'ai pas de soucis de NAT (jusque ~8500 tout du moins) et du v6 natif depuis quelques temps si jamais.