La Fibre

Fournisseurs d'accès à Internet fixe en France métropolitaine => Free => Free Actus FTTH => Discussion démarrée par: didjee34 le 26 février 2016 à 14:32:14

Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: didjee34 le 26 février 2016 à 14:32:14
Je crois que vous n'avez pas très bien suivi. Freewifi vérifierait le réseau d'où émane la demande de connexion, pour vérifier si c'est un réseau Free.

Le message d'erreur que voit toroyvaca est le suivant :

Donc rien à voir avec l'adresse IP du Freewifi lui-même.

Edit : Abel99 a même retrouvé une tâche ouverte sur le bugtracker :

http://dev.freebox.fr/bugs/task/19681

Oui c'est moi qui est ouvert ce ticket quand j'ai constaté le soucis sur la ligne de mes parents.

Depuis, j'ai migré également ma deuxieme ligne FTTH vers Free, et j'ai d'autres soucis qui vont je pense mériter des tickets chez eux.

1/ Un serveur Linux (Ubuntu 14.04 LTS ou Debian 8.3) au cul de la Freebox Mini 4K, impossible d'uploader (speedtest-cli) sans modifier la MTU de l'interface eth0 à 1472.

2/ Soucis en bypassant la freebox en mode bridge et en mettant à la place l'ERLite 3 (l'interface eth1 prend bien le DHCP et l'IP publique de la box) mais aucune resolution DNS possible (je pense que c'est le soucis de MTU 1472 qu'il faudrait que je reteste avec l'ERLite)

3/ Soucis pour maintenir un tunnel OpenVPN sous Debian / Ubuntu au cul de la Freebox. => Impossible en mode UDP (connexion établie mais 0 flux possible)

=> Possibilité de lancer le tunnel OpenVPN en mode TCP mais avec un débit limité pour le moment sans cryptage / auth à 16 Mo/s avec le serveur dédié (qui est en interface gigabit), le pire étant pour le moment qu'il est du coup impossible de maximiser la MTU du tun0/tap0 pour optimiser les performances.

Bref, pour le moment cette solution IP shared ne me convient pas vraiment... quid de la possibilité d'avoir une IP dédiée (via option payante ou pas) ? Quand ?

Didier

Titre: FTTH ZMD: Free fait du DS-Lite
Posté par: alain_p le 26 février 2016 à 14:48:47
L'IP dédiée, Rani a dit que l'option serait gratuite, et que l'on pourrait même avoir plusieurs IP (option payante). Mais on attend toujours sa réponse sur la date de disponibilité de l'option...

Pour moi, en ZMD, c'est toujours en beta-test. Mais chez Free, on l'a souvent vu (freebox v6, 4K etc...), on peut être en beta-test et en même temps en étape de commercialisation. Il vaut mieux attendre que les soucis soient réglés avant de souscrire...

P.S : au fait, tu as quel range de ports ?
Titre: FTTH ZMD: Free fait du DS-Lite
Posté par: zoc le 26 février 2016 à 14:54:33
2/ Soucis en bypassant la freebox en mode bridge et en mettant à la place l'ERLite 3 (l'interface eth1 prend bien le DHCP et l'IP publique de la box) mais aucune resolution DNS possible (je pense que c'est le soucis de MTU 1472 qu'il faudrait que je reteste avec l'ERLite)
Moi je crois plutôt que comme l'ERL n'est pas au courant qu'il n'a pas droit à tous les ports, manque de chance le port source choisi pour les requêtes DNS (si tu utilises dnsmasq sur l'ERL) ne fait pas partie du range qui t'es attribué, et du coup la réponse "va chez ton voisin".

Personnellement j'ai du mal à voir comment le mode bridge peut fonctionner sans indiquer explicitement au routeur quelle plage de ports il peut utiliser.

Titre: FTTH ZMD: Free fait du DS-Lite
Posté par: kgersen le 26 février 2016 à 15:00:11
Moi je crois plutôt que comme l'ERL n'est pas au courant qu'il n'a pas droit à tous les ports, manque de chance le port source choisi pour les requêtes DNS (si tu utilises dnsmasq sur l'ERL) ne fait pas partie du range qui t'es attribué, et du coup la réponse va chez ton voisin.

Personnellement j'ai du mal à voir comment le mode bridge peut fonctionner sans indiquer explicitement au routeur quelle plage de ports il peut utiliser.

Il se peut aussi qu'en mode bridge la V6 fasse aussi de la translation des ports clients.

Cette histoire de MTU  est curieux par contre. Ce pourra indiquer qu'IPv4 est transporté par IPv6 contrairement a ce qu'on croyait ?

donc on a des tunnels sur IPv6 vers des gateway A+P qui en option pourront filer une IP complete sur demande ? c'est en fait du NAT64 stateless sans le coté 'dynamique' de suivre les ports ouverts ?
Titre: FTTH ZMD: Free fait du DS-Lite
Posté par: didjee34 le 26 février 2016 à 15:07:37
L'IP dédiée, Rani a dit que l'option serait gratuite, et que l'on pourrait même avoir plusieurs IP (option payante). Mais on attend toujours sa réponse sur la date de disponibilité de l'option...

Pour moi, en ZMD, c'est toujours en beta-test. Mais chez Free, on l'a souvent vu (freebox v6, 4K etc...), on peut être en beta-test et en même temps en étape de commercialisation. Il vaut mieux attendre que les soucis soient réglés avant de souscrire...

P.S : au fait, tu as quel range de ports ?

Pour info, sur ma ligne Free FTTH ZMD j'ai gagné à la loterie et j'ai le premier range [0 - 15000] (ou quelque chose comme ça). C'est sur cette ligne que j'ai fais les tests d'OpenVPN.

Je vais refaire joujou avec l'ERLite 3 ports et la freebox en mode bridge jusqu'à trouver le pourquoi du comment.

Et pour le CGNAT, je pense que c'est pour ça que le tunnel OpenVPN UDP ne passe pas aussi. (Il faut que je teste à partir d'un poste sous Windows)

Didier
Titre: FTTH ZMD: Free fait du DS-Lite
Posté par: alain_p le 26 février 2016 à 15:34:10
Cette histoire de MTU  est curieux par contre. Ce pourra indiquer qu'IPv4 est transporté par IPv6 contrairement a ce qu'on croyait ?

donc on a des tunnels sur IPv6 vers des gateway A+P qui en option pourront filer une IP complete sur demande ? c'est en fait du NAT64 stateless sans le coté 'dynamique' de suivre les ports ouverts ?

Il me semble au contraire que c'est ce que l'on disait depuis le début. D'après Vivien, et les tests de traceroute effectués, on ne peut pas tracer l'IP, car cela sort d'un tunnel IPv6 sur un routeur free à Paris (cf cyberjuls). Donc il y a peut-être effectivement un en-tête d'encapsulation à rajouter/déduire ?
Titre: FTTH ZMD: Free fait du DS-Lite
Posté par: kgersen le 26 février 2016 à 16:08:20
Il me semble au contraire que c'est ce que l'on disait depuis le début. D'après Vivien, et les tests de traceroute effectués, on ne peut pas tracer l'IP, car cela sort d'un tunnel IPv6 sur un routeur free à Paris (cf cyberjuls). Donc il y a peut-être effectivement un en-tête d'encapsulation à rajouter/déduire ?

Ca n'était pas tranché en fait. si tu relis quelques pages à  partir d'ici https://lafibre.info/free-la-fibre/cgn-14-chez-free-une-ipv4-partagee-par-4-clients/msg283323/#msg283323.

On n'avait pas eu de confirmation du MTU en IPv4 car personne n'a fait de mesure (ou l'info m'a échappé). On en était resté a un A+P sans tunnel (curieux j'admet).

Cet nouvelle info de MTU semble indiqué des tunnels donc un NAT64, en fait un DS-Lite plutot (le NAT64 n'implique pas d'IPv4 coté client).

Donc Free ferait du DS-Lite avec NAT stateless pré-partagé une IP pour 4, les gateway DS-Lite étant en IDF (pour le moment).
C'est effectivement plus facile de proposer des IP full en option sur ce genre d'archi et ca permet le Pass-thru du VPN.

Ca clarifie nettement les choses. Ca veut dire aussi qu'en mode bridge la Freebox fait toujours le tunnel 4in6 donc on doit pouvoir mettre son propre routeur sans souci si on rêgle bien le MTU.
Titre: FTTH ZMD: Free fait du DS-Lite
Posté par: alain_p le 26 février 2016 à 17:30:15
Je ne connaissais pas DS-Lite, et donc je me suis un peu renseigné. Cela semble tout à fait cela. Et donc la freebox n'aurait pas d'adresse IPv4 publique, c'est le routeur au bout du tunnel qui ferait la passerelle vers IPv4. L'article wikipedia en anglais me semble assez clair, et surtout le schéma qui l'accompagne :

Citer
Dual-Stack Lite technology does not involve allocating an IPV4 address to customer-premises equipment (CPE) for providing Internet access. It is described in RFC 6333. The CPE distributes private IPv4 addresses for the LAN clients, according to the networking requirement in the local area network. The CPE encapsulates IPv4 packets within IPv6 packets. The CPE uses its global IPv6 connection to deliver the packet to the ISP's Carrier-grade NAT (CGN), which has a global IPv4 address. The original IPv4 packet is recovered and NAT is performed upon the IPv4 packet and is routed to the public IPv4 Internet. The CGN uniquely identifies traffic flows by recording the CPE public IPv6 address, the private IPv4 address, and TCP or UDP port number as a session.[16]

https://en.wikipedia.org/wiki/IPv6_transition_mechanism#Dual-Stack_Lite_.28DS-Lite.29
Titre: FTTH ZMD: Free fait du DS-Lite
Posté par: corrector le 26 février 2016 à 17:39:30
Je ne connaissais pas DS-Lite, et donc je me suis un peu renseigné. Cela semble tout à fait cela. Et donc la freebox n'aurait pas d'adresse IPv4 publique, c'est le routeur au bout du tunnel qui ferait la passerelle vers IPv4. L'article wikipedia en anglais me semble assez clair, et surtout le schéma qui l'accompagne :

https://en.wikipedia.org/wiki/IPv6_transition_mechanism#Dual-Stack_Lite_.28DS-Lite.29
Sauf que la partie
Citer
The original IPv4 packet is recovered and NAT is performed upon the IPv4 packet and is routed to the public IPv4 Internet. The CGN uniquely identifies traffic flows by recording the CPE public IPv6 address, the private IPv4 address, and TCP or UDP port number as a session.
est fausse : pas de CGN, pas de "recording", même pas de NAT.
Titre: FTTH ZMD: Free fait du DS-Lite
Posté par: alain_p le 26 février 2016 à 17:43:13
Un article du blog de Stéphane Bortzmeyer à propos de DS-Lite :

http://www.bortzmeyer.org/6333.html

P.S : Bortzmeyer était visionnaire en 2011, quand il a écrit ce billet :

Citer
Mais déplacer la fonction NAT depuis une machine située chez l'utilisateur vers le réseau du FAI crée des nouveaux défis. Par exemple, les adresses IPv4 publiques, qui n'étaient partagées qu'entre les membres d'une même famille ou les employés d'une même entreprise, vont désormais être partagées entre des clients du même FAI, clients qui ne se connaissent pas. Si la HADOPI voit 203.0.113.201 commettre un crime grave (par exemple partager des œuvres d'art), et qu'elle veut couper l'utilisateur de cette adresse, la probabilité de bavure devient bien plus élevée. Enregistrer les adresses IP ne suffit donc plus, il faut noter l'adresse IP et le port (RFC 6302) et que l'AFTR enregistre ses tables de correspondance (identité du tunnel, protocole, adresses et ports), comme précisé en section A.4.
Titre: FTTH ZMD: Free fait du DS-Lite
Posté par: corrector le 26 février 2016 à 17:59:11
Un article du blog de Stéphane Bortzmeyer à propos de DS-Lite :

http://www.bortzmeyer.org/6333.html
Voilà :
Citer
L'AFTR doit donc faire attention à empêcher les utilisateurs de monter une DoS (volontairement ou par accident) en s'attribuant tous les ports possibles. Par exemple, l'AFTR peut limiter le rythme d'allocation des ports, ou bien mettre une limite absolue au nombre de ports qu'un B4 peut s'allouer.
C'est inapplicable.

Donc Free ne fait pas vraiment du DS-Lite.
Titre: FTTH ZMD: Free fait du DS-Lite
Posté par: alain_p le 26 février 2016 à 18:01:36
Pourquoi ce serait inapplicable ? Bortzmeyer cite même les solutions envisagées.
Titre: FTTH ZMD: Free fait du DS-Lite
Posté par: Darklight le 26 février 2016 à 18:04:38
Donc en résumant (sans savoir si c'est du DS-Lite) en ZMD chez Free :

Du coup le mécanisme qui fait le partage des "ports" entre 4 freebox, ainsi que le tunnel, est déporté sur le NRO?, ou cela se situe directement dans l'infra de Free? (un peu à la manière d'un LNS)
Titre: FTTH ZMD: Free fait du DS-Lite
Posté par: corrector le 26 février 2016 à 18:19:02
Pourquoi ce serait inapplicable ? Bortzmeyer cite même les solutions envisagées.
Parce que ça n'existe pas chez Free, tout simplement :
Citer
L'AFTR doit donc faire attention à empêcher les utilisateurs de monter une DoS (volontairement ou par accident) en s'attribuant tous les ports possibles. Par exemple, l'AFTR peut limiter le rythme d'allocation des ports, ou bien mettre une limite absolue au nombre de ports qu'un B4 peut s'allouer.
Il n'y a pas de "rythme d'allocation des ports" parce qu'il n'y a pas d'allocation dynamique.
Titre: FTTH ZMD: Free fait du DS-Lite
Posté par: didjee34 le 26 février 2016 à 18:47:20
Ca n'était pas tranché en fait. si tu relis quelques pages à  partir d'ici https://lafibre.info/free-la-fibre/cgn-14-chez-free-une-ipv4-partagee-par-4-clients/msg283323/#msg283323.

On n'avait pas eu de confirmation du MTU en IPv4 car personne n'a fait de mesure (ou l'info m'a échappé). On en était resté a un A+P sans tunnel (curieux j'admet).

Cet nouvelle info de MTU semble indiqué des tunnels donc un NAT64, en fait un DS-Lite plutot (le NAT64 n'implique pas d'IPv4 coté client).

Donc Free ferait du DS-Lite avec NAT stateless pré-partagé une IP pour 4, les gateway DS-Lite étant en IDF (pour le moment).
C'est effectivement plus facile de proposer des IP full en option sur ce genre d'archi et ca permet le Pass-thru du VPN.

Ca clarifie nettement les choses. Ca veut dire aussi qu'en mode bridge la Freebox fait toujours le tunnel 4in6 donc on doit pouvoir mettre son propre routeur sans souci si on rêgle bien le MTU.

Alors je vous confirme après avoir écarté le doute sur le driver ethernet de mon contrôleur ethernet Nvidia MCP79 (Nvidia ION)... que sur un routeur ERLite le soucis de la MTU se confirme.

A partir du ERLite 3 :


MTU 1472
root@ubnt# ifconfig eth0 mtu 1472
root@ubnt# tracepath www.free.fr
 1:  192.168.2.254                                         0.918ms pmtu 1472
 1:  192.168.2.1                                           0.620ms
 1:  192.168.2.1                                           0.652ms
 2:  194.149.164.0                                        14.179ms
 3:  p11-crs16-1-be1003.intf.routers.proxad.net           17.461ms
 4:  p11-9k-1-be1000.intf.routers.proxad.net              15.077ms
 5:  bzn-9k-2-sys-be2001.intf.routers.proxad.net          14.872ms
 6:  no reply
 7:  no reply
 8:  no reply

MTU 1500
root@ubnt# ifconfig eth0 mtu 1500
root@ubnt# tracepath www.free.fr
 1:  192.168.2.254                                         0.835ms pmtu 1500
 1:  192.168.2.1                                           0.571ms
 1:  192.168.2.1                                           0.544ms
 2:  no reply
 3:  no reply
 4:  no reply
 5:  no reply

Serveur debian 8 :

MTU 1500
root@vpnbox:~# tracepath www.free.fr
 1?: [LOCALHOST]                                         pmtu 1500
 1:  192.168.2.1                                           0.330ms
 1:  192.168.2.1                                           0.269ms
 2:  no reply
 3:  no reply

MTU 1472
root@vpnbox:~# ifconfig eth0 mtu 1472
root@vpnbox:~# tracepath www.free.fr
 1?: [LOCALHOST]                                         pmtu 1472
 1:  192.168.2.1                                           0.322ms
 1:  192.168.2.1                                           0.260ms
 2:  194.149.164.0                                        13.980ms
 3:  p11-crs16-1-be1003.intf.routers.proxad.net           18.045ms
 4:  p11-9k-1-be1000.intf.routers.proxad.net              15.521ms
 5:  bzn-9k-2-sys-be2001.intf.routers.proxad.net          14.505ms
 6:  no reply

Merci Rani ;)


P.S :
J'ai également revérifier la configuration de mon serveur OpenVPN sur ma dédibox, en établissant un tunnel vers un serveur Amazon EC2 en zone Europe, je cartonne bien à plus de 600 Mbit/s en DL / UP sur mon dédié.

Je vais refaire des tests de débits avec iperf3 avec le tunnel OpenVPN de chez moi mais c'est clairement pas cool du tout...

P.S2 : test rejoué avec iperf3 dans les 2 sens, en encapsulant dans un stunnel (ou sans) l'OpenVPN, uniquement en TCP du coup : débit max 180 Mbit/s UP / DL via OpenVPN


Didier
Titre: FTTH ZMD: Free fait du DS-Lite
Posté par: corrector le 26 février 2016 à 18:58:50
La Freebox annonce quel MTU?
Titre: FTTH ZMD: Free fait du DS-Lite
Posté par: vivien le 26 février 2016 à 19:34:07
1/ Un serveur Linux (Ubuntu 14.04 LTS ou Debian 8.3) au cul de la Freebox Mini 4K, impossible d'uploader (speedtest-cli) sans modifier la MTU de l'interface eth0 à 1472.
MTU max à 1472 en IPv4 ou en IPv6 ? Les deux sont indépendants.

Comment cela se passe sous Windows avec une MTU par défaut à 1500 octets ? Il serait intéressant de prendre une capture Wireshark pour comprendre.

fragmentation des paquets par la box ? Pourquoi sous Windows et pas sous Linux ?
Titre: FTTH ZMD: Free fait du DS-Lite
Posté par: alain_p le 26 février 2016 à 19:38:33
Si l'IPv4 est encpasulé dans IPv6, et pas l'IPv6, ce dernier devrait avoir un MTU plus grand, normalement 1500.
Titre: FTTH ZMD: Free fait du DS-Lite
Posté par: didjee34 le 26 février 2016 à 19:38:42
MTU max à 1472 en IPv4 ou en IPv6 ? Les deux sont indépendants.

Comment cela se passe sous Windows avec une MTU par défaut à 1500 octets ? Il serait intéressant de prendre une capture Wireshark pour comprendre.

fragmentation des paquets par la box ? Pourquoi sous Windows et pas sous Linux ?

La stack IPv6 est désactivé sur mon serveur Debian 8 lors de mes tests (et de façon générale en fait).

Et l'option IPv6 n'est pas activée sur la Freebox.

Didier
Titre: FTTH ZMD: Free fait du DS-Lite
Posté par: alain_p le 26 février 2016 à 19:45:12
Et pourquoi désactives-tu l'IPv6 ? Dans ton cas elle pourrait bien t'aider. Si c'est une question de sécurité, perso, je n'ai aps encore vu de problème en IPv6. Il faudrait d'ailleurs s'il y a un pare-feu par défaut en IPv6 sur la freebox, mais sous windows, il y a au moins celui du PC. Sous linux, c'est possible aussi.

P.S : underground, tu pourrais suggérer à toriyvaca d'activer l'IPv6, pour voir si cela résout ses problèmes de connexion https et d'authentification Freewifi.
Titre: FTTH ZMD: Free fait du DS-Lite
Posté par: didjee34 le 26 février 2016 à 19:49:38
Et pourquoi désactives-tu l'IPv6 ? Dans ton cas elle pourrait bien t'aider. Si c'est une question de sécurité, perso, je n'ai aps encore vu de problème en IPv6. Il faudrait d'ailleurs s'il y a un pare-feu par défaut en IPv6 sur la freebox, mais sous windows, il y a au moins celui du PC. Sous linux, c'est possible aussi.

Disons que je n'en vois pas vraiment l'utilité, ni le bénéfice pour mon utilisation actuelle. Maintenant, si pour une obscure raison propre au SI Free, le fait de l'activer permet de nativement bypasser les restrictions que je constate... je vais peut être m'intéresser à basculer mon tunnel VPN sur de l'IPv6.

Pour info, je viens de regarder sous Windows je suis en MTU 1500 par default.
Titre: FTTH ZMD: Free fait du DS-Lite
Posté par: alain_p le 26 février 2016 à 19:53:17
Disons que comme l'IPv6 semble la configuration par défaut (l'IPv4 est encapsulé dans l'IPv6), tu as des chances que ton adresse IPv6 soit mieux reconnue (pour se connecter sur le site Freewifi par exemple) que ton adresse IPv4, qui ne serait pas sur ta box...
Titre: FTTH ZMD: Free fait du DS-Lite
Posté par: corrector le 26 février 2016 à 20:11:14
P.S : underground, tu pourrais suggérer à toriyvaca d'activer l'IPv6, pour voir si cela résout ses problèmes de connexion https et d'authentification Freewifi.
Je ne vois pas comment : wifi.free.fr = 212.27.40.236

(et les sites EDF ne semblent pas dispo en IPv6 non plus)
Titre: FTTH ZMD: Free fait du DS-Lite
Posté par: corrector le 26 février 2016 à 20:17:35
Donc en résumant (sans savoir si c'est du DS-Lite) en ZMD chez Free :

  • IPv6 native
  • IPv4 portée à travers IPv6 avec un mtu de 1472 octets
Du coup le mécanisme qui fait le partage des "ports" entre 4 freebox, ainsi que le tunnel, est déporté sur le NRO?, ou cela se situe directement dans l'infra de Free? (un peu à la manière d'un LNS)
Avec l'IPv6 en natif, et l'IPv4 non natif et partagé, on a "enfin" l'Internet v6 en première classe et le v4 en classe moisie.
Titre: Manque d'IPv4 chez Free: Une IPv4 est partagée par 4 clients avec 1/4 des ports
Posté par: Darklight le 26 février 2016 à 20:20:05
Disons que je n'en vois pas vraiment l'utilité, ni le bénéfice pour mon utilisation actuelle. Maintenant, si pour une obscure raison propre au SI Free, le fait de l'activer permet de nativement bypasser les restrictions que je constate... je vais peut être m'intéresser à basculer mon tunnel VPN sur de l'IPv6.

Pour info, je viens de regarder sous Windows je suis en MTU 1500 par default.
Donc tu es entrain de dire qu'un traceroute avec un MTU de 1500 fonctionne avec Windows? Il faudrait refaire tes tests effectués précédemment, ça me parait bizarre que ce soit juste Linux qui soit limité à 1472 octets en IPv4 ...
Titre: FTTH ZMD: Free fait du DS-Lite
Posté par: alain_p le 26 février 2016 à 20:28:28
Donc en résumant (sans savoir si c'est du DS-Lite) en ZMD chez Free :

  • IPv6 native
  • IPv4 portée à travers IPv6 avec un mtu de 1472 octets
Du coup le mécanisme qui fait le partage des "ports" entre 4 freebox, ainsi que le tunnel, est déporté sur le NRO?, ou cela se situe directement dans l'infra de Free? (un peu à la manière d'un LNS)

A mon avis, comme le tunnel IPv6 ressort sur un routeur à Courbevoie, et que la freebox ne porterait pas d'IPv4, et que ce serait du DS-Lite, le partage des ports se fait sur ce routeur à Courbevoie.
Titre: Manque d'IPv4 chez Free: Une IPv4 est partagée par 4 clients avec 1/4 des ports
Posté par: alain_p le 26 février 2016 à 20:31:01
Donc tu es entrain de dire qu'un traceroute avec un MTU de 1500 fonctionne avec Windows? Il faudrait refaire tes tests effectués précédemment, ça me parait bizarre que ce soit juste Linux qui soit limité à 1472 octets en IPv4 ...

Windows est en dual stack par défaut. Le DHCP de la box lui attribuerait une adresse IPv6 avec laquelle il ressortirait directement ?
Titre: FTTH ZMD: Free ferait du DS-Lite (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: vivien le 26 février 2016 à 20:33:34
Attention, pour Speedtest, de nombreux serveurs sont par défaut en IPv6 (c'est le cas de celui de Massy par exemple)


Pour revenir sur le DS-Lite :
En DS-Lite, l'ouverture des ports pour l'IPv4, se fait sur l’équipement réseau qui porte l'IPv4 publique, non ?

Si Free faisait du DS-Lite, les paramètres de configuration du NAT dans l'interface de la Freebox server seraient désactivés en IPv4, non ? (modification uniquement par le compte client qui programme l'équipement réseau)
Titre: FTTH ZMD: Free fait du DS-Lite
Posté par: corrector le 26 février 2016 à 20:39:22
Moi je crois plutôt que comme l'ERL n'est pas au courant qu'il n'a pas droit à tous les ports, manque de chance le port source choisi pour les requêtes DNS (si tu utilises dnsmasq sur l'ERL) ne fait pas partie du range qui t'es attribué, et du coup la réponse "va chez ton voisin".
J'espère que les paquets avec les ports non autorisés sont détruits!!!

L'idéal serait de générer un ICMP erreur (dest-unreach? de paramètres?)
Titre: Manque d'IPv4 chez Free: Une IPv4 est partagée par 4 clients avec 1/4 des ports
Posté par: corrector le 26 février 2016 à 20:43:43
Windows est en dual stack par défaut. Le DHCP de la box lui attribuerait une adresse IPv6 avec laquelle il ressortirait directement ?
Pardon?

Il y a du DHCPv6 sur la Freebox maintenant?
Titre: FTTH ZMD: Free ferait du DS-Lite (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: Darklight le 26 février 2016 à 20:46:10
Windows est en dual stack par défaut. Le DHCP de la box lui attribuerait une adresse IPv6 avec laquelle il ressortirait directement ?
Non en IPV4 ça ressort encapsulé en IPv6 mais derrière la box (qui est uniquement en IPv6 native en ZMD).

Du coup cette histoire de MTU est bizarre, faudrait refaire le test, un ping ou traceroute avec Windows vers une IPv4 pour être sur...
Titre: Manque d'IPv4 chez Free: Une IPv4 est partagée par 4 clients avec 1/4 des ports
Posté par: alain_p le 26 février 2016 à 20:48:10
Pardon?

Il y a du DHCPv6 sur la Freebox maintenant?

Forcèment, si tout passe par un tunnel IPv6. Mais la box elle-même n'est pas forcée de porter une adresse IPv6 adressable de l'extérieur (pas le même VLAN ?).
Titre: FTTH ZMD: Free ferait du DS-Lite (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: vivien le 26 février 2016 à 20:50:31
Il y a plusieurs solutions pour attribuer une IPv6 à un client et il me semble que DHCPv6 n'est pas utilisé par Free.
Titre: FTTH ZMD: Free ferait du DS-Lite (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: kgersen le 26 février 2016 à 20:52:07
En DS-Lite, l'ouverture des ports pour l'IPv4, se fait sur l’équipement réseau qui porte l'IPv4 publique, non ?

Si Free faisait du DS-Lite, les paramètres de configuration du NAT dans l'interface de la Freebox server seraient désactivés en IPv4, non ? (modification uniquement par le compte client qui programme l'équipement réseau)

A mon avis, la gateway DS-Lite laisse tout passer en entrée, c'est la freebox qui bloque ou pas. La gateway se contente juste de mettre IPv4 dans un tunnel IPv6 et l'envoyé

Internet ---> ipv4 dest port X --> gateway DS-lite avec A+P --> ipv4 dans ipv6 vers la box correspondante a X (suivant le 1/4 de ports) --> Freebox (si X ouvert pour entrer ca entre sinon ca bloque ici) --> lan

La gateway est complètement stateless, elle ne track aucune connexion. Elle doit être performante car il y a un trafic important qui passe la.

Dans les faits c'est sans doute du 4rd mais le principe du DS-Lite est plus connu pour comprendre comme ca marche. C'est tres proche sauf que le 4rd fait des tunnels comme le 6rd donc de box a box en IPv6 quand le traffic IPv4 est d'un abonné a l'autre.

la rfc de 2015 a ce sujet: https://tools.ietf.org/html/rfc7600
Titre: FTTH ZMD: Free ferait du DS-Lite (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: Darklight le 26 février 2016 à 20:52:46
Forcèment, si tout passe par un tunnel IPv6. Mais la box elle-même n'est pas forcée de porter une adresse IPv6 adressable de l'extérieur (pas le même VLAN ?).
Contrairement aux zones ADSL dégroupées qui sont en 6rd, là c'est l'inverse : tout passe en IPv6 native et l'IPv4 est encapsulée dans l'IPv6 avec la freebox (pour la première fois!) mais on cherche quel protocole encapsule l'IPv4. Et pour le coup, le MTU est plus faible, ce qui peut donner un indice sur le proto utilisé. Mais là encore, c'est pas certain certain (d'où mes messages précédents)
Titre: FTTH ZMD: Free ferait du DS-Lite (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: corrector le 26 février 2016 à 20:55:01
Attention, pour Speedtest, de nombreux serveurs sont par défaut en IPv6 (c'est le cas de celui de Massy par exemple)


Pour revenir sur le DS-Lite :
En DS-Lite, l'ouverture des ports pour l'IPv4, se fait sur l’équipement réseau qui porte l'IPv4 publique, non ?

Si Free faisait du DS-Lite, les paramètres de configuration du NAT dans l'interface de la Freebox server seraient désactivés en IPv4, non ? (modification uniquement par le compte client qui programme l'équipement réseau)
Oui.

Mais il ne s'agit justement pas de DS-Lite.
Titre: Manque d'IPv4 chez Free: Une IPv4 est partagée par 4 clients avec 1/4 des ports
Posté par: kgersen le 26 février 2016 à 20:56:09
En ZMD: "Activer IPv6 dans la Freebox" c'est juste coté LAN. Coté WAN ca ne change pas, la freebox ne peut fonctionner sans IPv6.
Titre: FTTH ZMD: Free ferait du DS-Lite (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: kgersen le 26 février 2016 à 21:01:26
tout les indices pointent vers le 4rd:

1 IP pour 4:
Citer
In order to deal with the IPv4 address shortage, customers can be
   assigned shared public IPv4 addresses with statically assigned
   restricted port sets
.  As such, it is a particular application of the
   Address plus Port (A+P) approach [RFC6346].

et en option une IP full ou plusieurs IP meme :
Citer
   Deploying 4rd in networks that have enough public IPv4 addresses,
   customer sites can also be assigned full public IPv4 addresses.  4rd
   also supports scenarios where a set of public IPv4 addresses are
   assigned to customer sites.
Titre: FTTH ZMD: Free ferait du DS-Lite (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: kgersen le 26 février 2016 à 21:03:48
voila le schema de fonctionnement:


                                    4rd Domain
                       +-----------------------------+
                       |        IPv6 routing         |
                       |  Enforced ingress filtering | +----------
                  ...  |                             | |
                       |                          +------+
        Customer site  |                          |BR(s) |  IPv4
        +------------+ |      BR IPv6 prefix  --> |and/or| Internet
        | dual-stack | |                          |N4T64+|
        |         +--+ |                          +------+
        |         |CE+-+ <-- a CE IPv6 prefix        | |
        |         +--+ |                             | +----------
        |            | |                             |
        +------------+ |     <--IPv4 tunnels-->      +------------
          => Derived   |  (Mesh or hub-and-spoke     |
        4rd IPv4 prefix|         topologies)         |    IPv6
                       |                             |  Internet
                  ...  |                             |
                       |                             +------------
                       +-----------------------------+
                      <== one or several Mapping rules
                  (e.g., announced to CEs in stateless DHCPv6)

           Figure 1: The 4rd Model in the Internet Architecture

Titre: FTTH ZMD: Free fait du DS-Lite
Posté par: Marin le 26 février 2016 à 21:05:11
On n'avait pas eu de confirmation du MTU en IPv4 car personne n'a fait de mesure (ou l'info m'a échappé).

https://lafibre.info/free-la-fibre/installation-freebox-revolution-optique-avec-convertisseur/msg283969/?topicseen#msg283969
https://lafibre.info/free-la-fibre/installation-freebox-revolution-optique-avec-convertisseur/msg283960/?topicseen#msg283960
?
Titre: FTTH ZMD: Free ferait du DS-Lite (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: corrector le 26 février 2016 à 21:16:17
Il y a plusieurs solutions pour attribuer une IPv6 à un client et il me semble que DHCPv6 n'est pas utilisé par Free.
Jusqu'à présent, non : l'IPv6 était en 6rd; la config 6rd devrait être inscrite en dur dans le script. (La config 6rd peut aussi être indiquée par DHCP.)

Mais là on passe de v6 dans v4 à v4 dans v6, donc la gestion des adresses change forcèment!

Par ailleurs DHCPv6 peut être utilisé sans que l'utilisateur puisse le savoir, sauf à remplacer la box par un "modem".
Titre: Manque d'IPv4 chez Free: Une IPv4 est partagée par 4 clients avec 1/4 des ports
Posté par: corrector le 26 février 2016 à 21:22:05
En ZMD: "Activer IPv6 dans la Freebox" c'est juste coté LAN. Coté WAN ca ne change pas, la freebox ne peut fonctionner sans IPv6.
Il n'y a JAMAIS eu d'option pour désactiver IPv6 SUR la Freebox.

D'ailleurs on ne peut pas non plus contrôler la réponse au ping en IPv6. Il n'y a pas d'option pour ça. (En tout cas pas sur Freebox v5.)
Titre: FTTH ZMD: Free ferait du DS-Lite (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: kgersen le 26 février 2016 à 21:24:10
Il n'y a JAMAIS eu d'option pour désactiver IPv6 SUR la Freebox.

D'ailleurs on ne peut pas non plus contrôler la réponse au ping en IPv6. Il n'y a pas d'option pour ça. (En tout cas pas sur Freebox v5.)

(http://aide.ma-freebox.fr/ipv6_revo_04.jpg)

ca n'existe plus ?
Titre: FTTH ZMD: Free ferait du DS-Lite (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: corrector le 26 février 2016 à 21:25:33
Cela n'a JAMAIS existé!

Désactive IPv6 et envoie moi ton IP.
Titre: FTTH ZMD: Free ferait du DS-Lite (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: kgersen le 26 février 2016 à 21:27:39
Je te parle coté LAN. ca doit coupé le radvd.
Titre: FTTH ZMD: Free ferait du DS-Lite (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: corrector le 26 février 2016 à 21:33:36
Pour revenir sur le DS-Lite :
En DS-Lite, l'ouverture des ports pour l'IPv4, se fait sur l’équipement réseau qui porte l'IPv4 publique, non ?

Si Free faisait du DS-Lite, les paramètres de configuration du NAT dans l'interface de la Freebox server seraient désactivés en IPv4, non ? (modification uniquement par le compte client qui programme l'équipement réseau)
Attention!

DS-Lite = NAPT = stateful
RFC 7600 = IPv4 Residual Deployment via IPv6 - A Stateless Solution (4rd)
Titre: FTTH ZMD: Free ferait du DS-Lite (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: corrector le 26 février 2016 à 21:34:35
Je te parle coté LAN. ca doit coupé le radvd.
Ah oui, on peut éviter d'informer le LAN de l'existence de IPv6.

Mais pas désactiver le support IPv6 sur la Freebox, ni le ping.
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: Darklight le 26 février 2016 à 22:20:57
Au final il y a un process de changement totalement inversé entre Free et Orange : en ZMD, Free part sur du 4rd géré par un/des gros routeur, plusieurs gateway IPv4 centralisées, tandis qu'Orange supprime progressivement les BAS et adresse plus localement.

La question, c'est de savoir si le 4rd et A+P va se généraliser sur l'ensemble du réseau de Free, ou si cela va rester uniquement sur les ZMD? (sachant qu'il faut avoir l'IPv6 en natif)

Si Rani pourrait nous éclairer, ça serait super ;)
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: corrector le 26 février 2016 à 22:32:40
Free/Orange :

(https://upload.wikimedia.org/wikipedia/commons/thumb/1/17/Yin_yang.svg/240px-Yin_yang.svg.png?uselang=fr)
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: hwti le 27 février 2016 à 00:12:39
Si on a réellement MTU=1472 en IPv4, en TCP il suffit que la Freebox modifie le MSS, donc les problèmes sous Linux sont étranges.
Est-ce qu'on a des captures côté serveur ?
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: vivien le 27 février 2016 à 08:10:07
Il me semble évident que la Freebox doit modifier le MSS dans les paquets [SYN] et [SYN-ACK] de TCP, comme c'est le cas en zone non dégroupée (40 octets de perdu par le tunnel L2TP)

Je suis à disposition pour faire des traces serveur pendant qu'une personne fait des traces coté client avec un MTU à 1500 octets.
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: Darklight le 27 février 2016 à 16:56:49
En mode bridge, le MSS est quand même ajusté par la freebox?
Il semble que notre ami utilise sa box en mode bridge
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: corrector le 27 février 2016 à 17:09:31
Mode soi-disant bridge...
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: alain_p le 27 février 2016 à 19:15:55
Il y a un point qui ne me parait pas clair dans ce qui a été dit dans ce sujet, c'est l'histoire du MTU. D'après les liens cités par Marin, cyberjuls avait mesuré un MTU de 1500, aussi bien en linux qu'en windows :

https://lafibre.info/free-la-fibre/installation-freebox-revolution-optique-avec-convertisseur/msg283969/?topicseen#msg283969
https://lafibre.info/free-la-fibre/installation-freebox-revolution-optique-avec-convertisseur/msg283960/?topicseen#msg283960

Didjee34 parle d'un MTU de 1472 quand il est en Linux, et de 1500 quand il teste avec windows, ce qui, comme l'a relevé Darklight, ne paraît pas cohérent.

D'autre part, j'ai trouvé un lien qui semble indiquer que l'en-tête d'un tunnel IPv6 pour l'IPv4 serait de 40 octets (en particulier pour DS-lite, mais je pense que c'est la même chose pour 4rd ?) :
http://www.networkworld.com/article/2224654/cisco-subnet/mtu-size-issues.html

Par ailleurs, 1472 est une valeur particulière, c'est celle du paquet ICMP, auquel il faut rajouter 20 octets pour l'en-tête IP, et 8 pour ICMP, pour faire justement 1500 octets...

En fait, est-ce que l'on ne serait pas avec un MTU standard de 1500, et les conditions de didjee34 (mode bridge), induirait une erreur sous Linux ?

Ce qui me fait dire cela, c'est que je viens de lire dans la description du protocole DS-Lite, qu'il est recommandé d'ajouter 40 octets, justement pour que la trame IPv4 fasse toujours 1500 :

Citer
Using an encapsulation (IPv4-in-IPv6 or anything else) to carry IPv4 traffic over IPv6 will reduce the effective MTU of the datagram.
Unfortunately, path MTU discovery [RFC1191] is not a reliable method to deal with this problem.

A solution to deal with this problem is for the service provider to increase the MTU size of all the links between the B4 element and the
AFTR elements by at least 40 bytes to accommodate both the IPv6 encapsulation header and the IPv4 datagram without fragmenting the
IPv6 packet.

http://tools.ietf.org/html/rfc6333   Paragraphe 5.3

P.S : si c'était vrai, cela voudrait dire que le MTU en IPv6 serait de 1540, ce qu'il est possible de vérifier.
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: kgersen le 27 février 2016 à 20:09:12
Je ne suis pas convaincu que les bons tests de mtu ont été fait (ping avec DF=1).

Le 4rd fragmente de lui meme un paquet IPv4 trop grand (coté freebox en sortie ou coté gateway en entrée).Donc on ne voit rien de spécial si on ne sait pas faire un bon test. Il ne faut pas confondre IPv6 = "on ne fragmente pas entre les 2 bouts" et IPv4 = "on peut fragmenter entre les 2 bouts".

Citer
   R-14: If an IPv4 packet enters a CE or BR with a size such that the
         derived Tunnel packet would be longer than the Domain PMTU, the
         packet has to be either discarded or fragmented.  The
         Domain-entry node MUST discard it if the packet has DF = 1,
         with an ICMP error message returned to the source.  It MUST
         fragment it otherwise
, with the payload of each fragment not
         exceeding PMTU - 48.  The first fragment has its offset equal
         to the received offset.  Subsequent fragments have offsets
         increased by the lengths of the payloads of previous fragments.
         Functionally, fragmentation is supposed to be done in IPv4
         before applying reversible header translation to each fragment;
         see Section 4.3.
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: alain_p le 27 février 2016 à 20:56:44
En tout cas, le MTU du paquet IPv4 ne peut pas être de 1472, avec un MTU "normal" de 1500, car l'en-tête d'un paquet IPv6 fait au minimum 40 octets, auquel peut se rajouter éventuellement d'autres informations, comme par exemple le type de protocole transporté, etc...

https://en.wikipedia.org/wiki/IPv6_packet

Si en IPv4, le MTU est de 1472, la taille du paquet IPv6 qui l'encapsule est au minimum de 1472 + 40 = 1512.

Rq : je ne vois pas comment si le paquet IPv6 n'est pas fragmenté entre les deux bouts, comment le paquet IPv4 pourrait l'être. A mon avis, il ne peut être fragmenté qu'avant l'entrée dans le tunnel, avant l'encapsulation. Si le paquet IPv6 peut être fragmenté, alors sa charge, le paquet IPv4 le sera aussi, même si c'est reconstitué plus loin.

P.S : En 6rd, le paquet IPv6 est encapsulé dans une trame IPv4. Comme l'en-tête du paquet IPv4 est de 20 octets, le MTU du paquet IPv6 est de 1480.
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: corrector le 27 février 2016 à 21:01:29
Qui a dit qu'un paquet IPv4 était la charge utile d'un paquet IPv6?
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: alain_p le 27 février 2016 à 21:07:10
Si le paquet IPv4 est réparti entre deux paquets IPv6, il est fragmenté, non ? S'il n'est pas fragmenté, il est dans une seule trame IPv6 ?
Voir la référence sur DS-Lite que j'ai donnée plus haut.
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: corrector le 27 février 2016 à 21:19:04
Oui, si le paquet est découpé dans plusieurs paquets lors de l'encapsulation, ça compte moralement comme une fragmentation.
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: alain_p le 27 février 2016 à 21:25:47
Plus que moralement, si l'un des paquets est perdu, tu demandes de renvoyer quoi ?
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: corrector le 27 février 2016 à 21:36:10
Si un paquet est perdu, et comme ce protocole d'encapsulation ne prévoit pas de faire des retransmissions, le tout est perdu.

Il y a des cas où le protocole d'encapsulation est basé sur TCP (ce que propose OVH) et donc gère lui même les retransmissions.

Il y a aussi le cas du Wifi qui découpe les paquets et qui gère les retransmissions, ainsi que l'ADSL. Dans ces deux cas l'opération est transparente.
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: alain_p le 27 février 2016 à 22:22:44
Oui, c'est possible. En tout cas, si la répartition d'une trame IPv4 entre deux trames IPv6 est bien comptée comme une fragmentation, ce qui serait naturel, alors si le MTU IPv4 est de 1500 octets, celui IPv6 est d'au moins 40 octets de plus, l'en-tête d'une trame IPv6, donc 1540.
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: corrector le 27 février 2016 à 22:26:27
Encore une fois, non!

Qui a dit qu'un paquet IPv4 était la charge utile d'un paquet IPv6?
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: alain_p le 27 février 2016 à 22:45:09
Et encore ? Si tu prenais le temps de t'expliquer ?
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: kgersen le 27 février 2016 à 22:47:07
en 4rd un paquet IPv4  n'est pas entier dans le payload IP d'un paquet IPv6.
Il y a un mapping reversible entre les entêtes IPv4 et les entêtes IPv6 et le payload IP est inchangé.
Suivant les cas on peut avoir besoin de place supplèmentaire (8 octets dans le cas présent), dans ce cas la norme IPv6 permet d'utiliser ce qu'on appelle un  "IPv6 Fragment Header" pour avoir plus de place.


                     (A) Without IPv6 fragment header
            IPv4 packet                          Tunnel packet
       +--------------------+ :            : +--------------------+
     20|     IPv4 Header    | :    <==>    : |     IPv6 Header    | 40
       +--------------------+ :            : +--------------------+
       |     IP Payload     |      <==>      |     IP Payload     |
       |                    |     Layer 4    |                    |
       +--------------------+    unchanged   +--------------------+


                     (B) With IPv6 fragment header
                                                 Tunnel packet
                                           : +--------------------+
            IPv4 packet                    : |     IPv6 Header    | 40
       +--------------------+ :            : +--------------------+
     20|     IPv4 Header    | :    <==>    : |IPv6 Fragment Header|  8
       +--------------------+ :            : +--------------------+
       |     IP Payload     |      <==>      |     IP Payload     |
       |                    |     Layer 4    |                    |
       +--------------------+    unchanged   +--------------------+


Ca n'est donc pas un tunnel comme en DS-lite, c'est un tunnel comme en 6rd mais ou les roles sont inversés.

lisez la RFC https://tools.ietf.org/html/rfc7600 si vous voulez tout les détails du mapping entre entêtes.
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: corrector le 27 février 2016 à 22:55:33
Et encore ? Si tu prenais le temps de t'expliquer ?
Pourquoi tu poses comme hypothèse l'approche la plus lourde en terme de surcharge protocolaire?

Tu supposerais que quand une marchandise arrive par camion, le camion est arrivé sur un train, le train sur la bateau et le bateau sur un avion (ou inversement)?
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: alain_p le 27 février 2016 à 22:57:23
en 4rd un paquet IPv4  n'est pas entier dans le payload IP d'un paquet IPv6.
Il y a un mapping reversible entre les entêtes IPv4 et les entêtes IPv6 et le payload IP est inchangé.
Suivant les cas on peut avoir besoin de place supplèmentaire (8 octets dans le cas présent), dans ce cas la norme IPv6 permet d'utiliser ce qu'on appelle un  "IPv6 Fragment Header" pour avoir plus de place.


                     (A) Without IPv6 fragment header
            IPv4 packet                          Tunnel packet
       +--------------------+ :            : +--------------------+
     20|     IPv4 Header    | :    <==>    : |     IPv6 Header    | 40
       +--------------------+ :            : +--------------------+
       |     IP Payload     |      <==>      |     IP Payload     |
       |                    |     Layer 4    |                    |
       +--------------------+    unchanged   +--------------------+


                     (B) With IPv6 fragment header
                                                 Tunnel packet
                                           : +--------------------+
            IPv4 packet                    : |     IPv6 Header    | 40
       +--------------------+ :            : +--------------------+
     20|     IPv4 Header    | :    <==>    : |IPv6 Fragment Header|  8
       +--------------------+ :            : +--------------------+
       |     IP Payload     |      <==>      |     IP Payload     |
       |                    |     Layer 4    |                    |
       +--------------------+    unchanged   +--------------------+


Ca n'est donc pas un tunnel comme en DS-lite, c'est un tunnel comme en 6rd mais ou les roles sont inversés.

lisez la RFC https://tools.ietf.org/html/rfc7600 si vous voulez tout les détails du mapping entre entêtes.

Si je comprends bien, le mapping permet de faire tenir l'en-tête IPv4 dans celui IPv6. Donc de combien est l'en-tête dans le cas de l'encapsulation 4rd, si on retire ce qui est commun avec IPv4 ? Comme l'en-tête IPv6 est de 40 octets, et celui IPv4 de 20 octets, cela ferait encore +20, et donc éventuellement le fragment header de 8, donc 28 ? Dans ce cas, on arriverait effectivement à 2472.
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: kgersen le 27 février 2016 à 23:17:45
oui si on veut éviter de la fragmentation il faut mettre un MTU a 1472. Mais en IPv4 ca n'est pas nécessaire de chercher a éviter la fragmentation.


Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: alain_p le 27 février 2016 à 23:18:29
Pourquoi tu poses comme hypothèse l'approche la plus lourde en terme de surcharge protocolaire?

Tu supposerais que quand une marchandise arrive par camion, le camion est arrivé sur un train, le train sur la bateau et le bateau sur un avion (ou inversement)?

En tout cas, c'est bien ce qu'il semble se passer dans un tunnel 4in6 :

Citer
IPv6 encapsulation consists of prepending to the original packet an IPv6 header and, optionally, a set of IPv6 extension headers

Voir : https://tools.ietf.org/html/rfc2473#section-3.1

D'où la recommandation sur DS-Lite que j'ai déjà citée :

Citer
A solution to deal with this problem is for the service provider to increase the MTU size of all the links between the B4 element and the
AFTR elements by at least 40 bytes to accommodate both the IPv6 encapsulation header and the IPv4 datagram without fragmenting the
IPv6 packet.


http://tools.ietf.org/html/rfc6333#section-5.3

Si tu étais un peu plus aimable ? Je préfère les explications détaiallées de kgersen.
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: alain_p le 27 février 2016 à 23:22:43
oui si on veut éviter de la fragmentation il faut mettre un MTU a 1472. Mais en IPv4 ca n'est pas nécessaire de chercher a éviter la fragmentation.

Mais on voit quand même avec ce MTU, ce qui était le but de opération, qu'il y a encapsulation dans un tunnel, et donc ce serait bien 4rd.
Maintenant, pourquoi en windows, ce serait quand même 1500 ? (et peut-être aussi sous linux avec cyberjuls).

L'autre solution, pour rester avec un MTU de 1500 en IPv4, serait d'augmenter le MTU IPv6 de 28, donc 1528.
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: kgersen le 27 février 2016 à 23:35:03
Je me répète mais on est certain des tests déja effectués?

le test canonique sous Windows est:

ping -4 -f -l 1472 lafibre.info
ce qui donne un MTU couche IP de 1500 (ping de 1472 + 8 icmp + 20 entete IPv4)

y'aurait pas une confusion du niveau du MTU (couche 3, couche 4) quelque part dans les échanges entre personnes ici ?

un MTU couche IP  de 1472 c'est un ping de ping de 1444 (- 8 icmp - 20 entete IPv4)

donc
ping -4 -f -l 1444 lafibre.infodoit passer
et
ping -4 -f -l 1445 lafibre.infone doit pas passer
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: corrector le 28 février 2016 à 01:28:22
Et encore ? Si tu prenais le temps de t'expliquer ?
Expliquer quoi?

J'ai tout dit. Tu fais une hypothèse que tu considères comme en soi évidente.

Je ne pense pas qu'elle le soit. Si elle l'est, démontre le!
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: tom pouce le 28 février 2016 à 03:18:41
"elle" ?
Quelle hypothèse ? Commence par expliquer ça, ce sera plus simple de te suivre.
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: corrector le 28 février 2016 à 03:25:10
Plus que moralement, si l'un des paquets est perdu, tu demandes de renvoyer quoi ?
Qui demande de renvoyer?

TCP? DNS? NFS?

En général, on demande au moins tout ce qu'on n'a pas reçu.
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: corrector le 28 février 2016 à 03:30:18
"elle" ?
Quelle hypothèse ? Commence par expliquer ça, ce sera plus simple de te suivre.
Cette hypothèse :
En tout cas, le MTU du paquet IPv4 ne peut pas être de 1472, avec un MTU "normal" de 1500, car l'en-tête d'un paquet IPv6 fait au minimum 40 octets, auquel peut se rajouter éventuellement d'autres informations, comme par exemple le type de protocole transporté, etc...

https://en.wikipedia.org/wiki/IPv6_packet

Si en IPv4, le MTU est de 1472, la taille du paquet IPv6 qui l'encapsule est au minimum de 1472 + 40 = 1512.
Il dit qu'un paquet IPv4 est la charge utile d'un paquet IPv6, au moins (peut être d'autres informations sont ajoutées).
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: tom pouce le 28 février 2016 à 03:52:29
Merci.
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: corrector le 28 février 2016 à 04:08:54
Si on raisonne en terme d'entropie, je pense que c'est plus clair.
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: hwti le 28 février 2016 à 04:51:33
Je ne suis pas convaincu que les bons tests de mtu ont été fait (ping avec DF=1).
Le test de cyberjuls était avec mturoute, qui positionne DF.
Mais comme ça semble tout de même en beta, rien ne dit que Free n'a pas changé des choses depuis.

Il y a peut-être aussi des bugs dans la Freebox, et le mode bridge est certainement moins testé.

Je pense qu'on y verrait plus clair en comparant les paquets capturés côté client et serveur (Vivien s'est proposé) dans les différentes configurations, même si l'idéal serait de voir ce qui transite entre le Freebox et le module SFP.
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: corrector le 28 février 2016 à 05:19:35
si la répartition d'une trame IPv4 entre deux trames IPv6 est bien comptée comme une fragmentation,
La répartition (terme bien trouvé!) EN SOI n'est pas une fragmentation ni pas-une-fragmentation.

C'est le comportement du système de transport du protocole machin au dessus du protocole trucmuche qui cause ou pas une fragmentation :

- si un paquet machin rentre d'un coté et deux ressortent alors c'est une fragmentation
- si un seul paquet ressort dans tous les cas, alors ce n'est pas forcèment une fragmentation

Le protocole ADSL transporte des trames ATM (ou autre) qui sont petites. Il y a répartition des trames PPP ou Ethernet ou IP mais il n'y a pas de fragmentation. C'est invisible pour la couche IP.

Le protocole Wifi découpe les trames Wifi=Ethernet en petites bouchées. Il y a répartition et pas fragmentation. C'est invisible pour la couche IP.

Pour que le découpage ne génère pas une fragmentation il faut que les trames soient reconstituées à l'autre bout. Si c'est le cas, on peut dire qu'il n'y a pas fragmentation.

Cependant, si les performances sont divisées par deux quand on augmente le MTU au delà d'une limite qui est haute, alors il faut classer ça comme fragmentation : imaginons un système utilisant 6in4 avec découpage des paquets trop grands et ré-assemblage des paquets IPv6 de l'autre coté. Sur un lien Ethernet ordinaire, on aurait MTU IPv4 = 1500; mettons que la MTU IPv6 est fixée par Ethernet à 1500, alors les paquets IPv6 jusqu'à 1480 passeront en une fois et ceux à partir de 1481 en deux fois. C'est ridicule parce que 1480 est une grande valeur et que la surcharge protocolaire grimpe énormèment.

D'un autre coté, imaginons un protocole qui transmet les paquets en découpant en blocs de 510 octets. Dans ce cas, ça n'a aucun sens de baisser la MTU.
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: alain_p le 28 février 2016 à 08:28:27
Je me répète mais on est certain des tests déja effectués?

Peut-être pas, tous les tests n'ont pas montré la ligne de commande utilisée. Ce serait bien de les refaire. Et surtout en IPv4 ET en en IPv6, pour voir s'il y a une différence.
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: corrector le 28 février 2016 à 09:22:32
en 4rd un paquet IPv4  n'est pas entier dans le payload IP d'un paquet IPv6.
Il y a un mapping reversible entre les entêtes IPv4 et les entêtes IPv6 et le payload IP est inchangé.
Disons que c'est du NAT464 1:1

Suivant les cas on peut avoir besoin de place supplèmentaire (8 octets dans le cas présent), dans ce cas la norme IPv6 permet d'utiliser ce qu'on appelle un  "IPv6 Fragment Header"
Plus précisèment la norme IPv6 ne dit rien : un champs "id" n'a pas plus de sémantique qu'un numéro de port (même moins).

pour avoir plus de place.
Je ne vois pas pourquoi tu parles de "place". Il s'agit juste de ne pas introduire un type de paquet différent pour le 4rd et d'utiliser des types existants.

C'est de la surcharge tout simplement.

Cela évite d'avoir à faire un enregistrement officiel IANA et d'utiliser une ressource en numérotation.
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: kgersen le 28 février 2016 à 15:31:55
La consequence d'utiliser du 4rd donc du partage d'header entre IP4 et IPv6 a des conséquences sur un traceroute en IPv4: celui ci affiche les nœuds IPv6 intermédiaires en IPv4 (adresse bidon)...contrairement a un vrai tunnel qui masque les nœuds intermédiaires.

Détails:
Citer
The effect of this TTL treatment on IPv4 traceroute is specific:
   (1) the number of routers of the end-to-end path includes traversed
   IPv6 routers; (2) IPv6 routers of a Domain are listed after IPv4
   routers of Domain entry and exit; (3) the IPv4 address shown for an
   IPv6 router is the IPv6-only dummy IPv4 address (Section 4.8 );
   (4) the response time indicated for an IPv6 router is that of the
   next router
trad:
Les effets qu'a ce traitement particulier du TTL  sur un traceroute IPv4 sont:
(1) le nombre de routeurs de bout en bout inclus les routeurs IPv6 traversés.
(2) les routeurs IPv6 du Domaine (=zone dans laquelle IPv4 est en "tunnel") sont listés après les routeurs IPv4 d'entree et de sortie du Domaine.
(3) l'IPv4 affichée pour un routeur IPv6 est la fausse IPv4 du 4rd (adresse réservée explicitement par l'IANA et valant 192.0.0.8/32).
(4) le temps de réponse qu'indique un routeur IPv6 est celui du prochain routeur

li serait intéressant d'avoir un traceroute IPv4 d'un abonné en ZMD Free pour voir si on peut constater cela.

traceroute dest:
PC
IPv4 freebox
IPv4 gateway 4rd
192.0.0.8 (R1) (ou pas de reponse?)
...
192.0.0.8 (Rn)
next hop IPv4
...
dest

PC -- lan -- (IPv4)freebox(IPv6) --- Routeur IPv6 R1 -- ... -- Routeur IPv6 Rn-- (IPv6)gateway 4rd (IPv4) -- next hop IPv4 ... Internet 4 ... dest


enfin, si j'ai bien compris ce passage et si Free respecte a 100% la rfc du 4rd.
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: vivien le 28 février 2016 à 15:56:33
Pour que le découpage ne génère pas une fragmentation il faut que les trames soient reconstituées à l'autre bout. Si c'est le cas, on peut dire qu'il n'y a pas fragmentation.

Le fait de découper les paquets et les reconstituer à l'autre bout génère une forte charge CPU sur les routeurs qui font ce travail.

Cela génère aussi de la gigue, les petits paquets qui ne nécessitent pas d'être découpés arrivent avant les plus gros qui sont passés par l'étape fragmentation / reconstitution.

Une capture wireshark permet de voir si ce type de comportement est effectué.

Il est plutôt conseillé de baisser la MSS dans les en-têtes TCP (modification du champ MSS des paquets TCP SYN et paquets TCP SYN-ACK).
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: Marin le 28 février 2016 à 16:02:10
li serait intéressant d'avoir un traceroute IPv4 d'un abonné en ZMD Free
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: alain_p le 28 février 2016 à 16:23:56
Rq : dans ces deux cas (cyberjuls et didjee34, à Castelnau Le Lez), on passe d'abord par l'adresse IPv4 194.149.164.0, puis on sort par le routeur de Bezons, p11-crs16-1-be1003.intf.routers.proxad.net. L'adresse IPv4 est pingable. Je ne sais pas à quoi correspond cette adresse IPv4. Quand je fais un traceroute, je l'atteins à travers le même routeur. Par contre, elle ne semble pas avoir de reverse DNS. Est-ce que c'est l'adresse d'une des interfaces du routeur, liée au "tunnel" 4rd ? l'adresse appartient à Online, dans la plage 194.149.160.0/19. J'ai l'impression que c'est cette adresse qui sert à la translation IPv6 vers IPv4.

P.S : cela pourrait correspondre à cette partie de la réponse de kgersen, mais sans utiliser l'adresse réservée par IANA ?
Citer
(3) l'IPv4 affichée pour un routeur IPv6 est la fausse IPv4 du 4rd (adresse réservée explicitement par l'IANA et valant 192.0.0.8/32).

P.S 2 : je remets le tracepath de didjee34 pour plus de clarté, à partir de son debian 8 :
MTU 1472
root@vpnbox:~# ifconfig eth0 mtu 1472
root@vpnbox:~# tracepath www.free.fr
 1?: [LOCALHOST]                                         pmtu 1472
 1:  192.168.2.1                                           0.322ms
 1:  192.168.2.1                                           0.260ms
 2:  194.149.164.0                                        13.980ms
 3:  p11-crs16-1-be1003.intf.routers.proxad.net           18.045ms
 4:  p11-9k-1-be1000.intf.routers.proxad.net              15.521ms
 5:  bzn-9k-2-sys-be2001.intf.routers.proxad.net          14.505ms
 6:  no reply

Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: kgersen le 28 février 2016 à 17:55:31
mouais pas tres concluant. y'a peut-etre un écart de mise en oeuvre chez Free.
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: alain_p le 28 février 2016 à 18:09:05
Je vois aussi que l'adresse 192.0.2.1 apparait dans le traceroute. Or le bloc 192.0.2.0/24 est réservé par IANA pour des documentations :

Citer
3.  Documentation Address Blocks

   The blocks 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2),
   and 203.0.113.0/24 (TEST-NET-3) are provided for use in
   documentation.

http://tools.ietf.org/html/rfc5737#section-3

Il est possible que Free ait ré-utilisé dans son implèmentation des adresses vues dans une documentation, et réservées pour cela...
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: Slothy le 28 février 2016 à 19:47:13
Bon, voici les résultats des tests réalisés sur la connexion Free de mon voisin.

Machine utilisée : DELL Precision M6600, i7 quadri coeur, 8 Gb de RAM et SSD connectée en direct en câble à la Freebox.

Speedtest :

(https://www.speedtest.net/result/5124828398.png)

Constatations :

-Le débit IPv6 est ridicule, de ce fait je n'ai pas pu terminer le test de neutralité
-Certains sites sont long à charger
-La MTU en IPv4 est de 1474
-La MTU en IPv6 est de 1480 1500
-Je n'ai pas pu me connecter au FTP de testdebit.info en IPv4 (encore une histoire de plage de port ça)
-Impossible d'activer le VPN de la Freebox, un truc du style "Vous ne pouvez pas activer cette fonctionnalité avec votre connexion" c'est sacrèment con de migrer sur la fibre pour au final pas pouvoir accéder à ton réseau
-L'espace client n'est pas du tout à jour, c'est comme si la migration fibre n'avait jamais été faite
-Le débit du Speedtest est bien limité par la connexion et non le PC, qui fait 950 Mb/s en FTTH SFR.

Des traceroutes :

Target Name: massy.testdebit.info
         IP: 194.158.102.114
  Date/Time: 28/02/2016 16:54:53 to 28/02/2016 16:55:09

Hop Sent Err  PL% Min Max Avg  Host Name / [IP]
 1    16   0  0,0   0   0   0  FREEBOX [192.168.0.254]
 2    16   0  0,0   3   3   3  [194.149.164.0]
 3    16   0  0,0   4  12   7  cbv-crs8-1-be1005.routers.proxad.net [78.254.249.78]
 4    16   0  0,0   3   5   3  th2-9k-1-be1003.intf.routers.proxad.net [78.254.249.97]
 5    15   2 13,3   3   4   3  la110.rpt02-th2.net.bbox.fr [194.117.192.9]
 6    16   0  0,0   3   4   3  [194.158.102.114]

Target Name: free.fr
         IP: 212.27.48.10
  Date/Time: 28/02/2016 16:55:17 to 28/02/2016 16:55:30

Hop Sent Err PL% Min Max Avg  Host Name / [IP]
 1    11   0 0,0   0   0   0  FREEBOX [192.168.0.254]
 2    10   0 0,0   3   3   3  [194.149.164.0]
 3    10   0 0,0   4  12   6  p11-crs16-1-be1003.intf.routers.proxad.net [78.254.249.101]
 4    10   0 0,0   3   5   3  p11-9k-1-be1000.intf.routers.proxad.net [78.254.249.130]
 5    10   0 0,0   3   3   3  bzn-9k-2-sys-be2001.intf.routers.proxad.net [194.149.161.246]
 6    10   0 0,0   3   4   3  www.free.fr [212.27.48.10]

Et le bon vieux HE.net qui ne va pas en s'arrangeant...

Target Name: tserv1.par1.he.net
         IP: 216.66.84.42
  Date/Time: 28/02/2016 16:58:11 to 28/02/2016 16:58:22

Hop Sent Err   PL% Min Max Avg  Host Name / [IP]
 1     9   0   0,0   0   0   0  FREEBOX [192.168.0.254]
 2     9   0   0,0   3   3   3  [194.149.164.0]
 3     9   0   0,0   3   9   6  cbv-crs8-1-be1005.routers.proxad.net [78.254.249.78]
 4     9   0   0,0   3   3   3  th2-9k-1-be1003.intf.routers.proxad.net [78.254.249.97]
 5     9   0   0,0  84  84  84  yankee-6k-1-po1.intf.routers.proxad.net [212.27.57.14]
 6     9   0   0,0  84  84  84  newyork-6k-1-po2.intf.routers.proxad.net [212.27.58.209]
 7     9   0   0,0 153 281 183  paloalto-6k-1-po1.intf.routers.proxad.net [212.27.58.222]
 8     6   6 100,0   0   0   0   [-]
 9     9   0   0,0 153 159 154  10ge7-5.core1.sjc2.he.net [72.52.92.70]
10     8   0   0,0 151 160 152  100ge1-2.core1.nyc4.he.net [184.105.81.214]
11     8   0   0,0 148 154 149  100ge11-1.core1.par2.he.net [184.105.81.78]
12     8   0   0,0 149 157 151  10ge3-1.core1.par1.he.net [184.105.213.89]
13     8   0   0,0 148 149 148  tserv1.par1.he.net [216.66.84.42]
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: alain_p le 28 février 2016 à 20:43:37
Très intéressant. Merci Slotthy. C'est la première fois que nous avons des tests en IPv4 et IPv6 en même temps, et aussi en windows.

Pour ta détermination du MTU, si je comprends bien, tu recherches le ping le plus long qui passe. Sous IPv4, tu as donc trouvé 1446. Si on rajoutes 20 octets d'en-tête IPv4 + 8 ICMP, on a bien 1446 + 20 +8 = 1474. Je suis étonné, je m'attendais à 1472, comme didjee34...
En IPv6, tu obtiens 1452. Pour moi, cela ne fait pas un MTU de 1480, mais de 1500, car l'en-tête IPv6 est de 40 octets, pas de 20 comme en IPv4. Donc, 1452 + 40 +8 = 1500. Donc on obtient un MTU normal de 1500 octets.

Cela confirme que l'IPv4 est encapsulé dans de l'IPv6, car la taille de la trame IPv6 est bien supérieure à celle IPv4, donc cela correspond bien plutôt à du 4rd. J'ai une interrogation sur la valeur de 1474 en IPv4, car on aurait du avoir 40 (header IPv6) - 20 (header IPv4 compris dans l'en-tête IPv6) + 8 (IPv6 fragmentation header), donc 28 à retrancher à 1500, donc 1472..

En tout cas, cela confirme aussi, comme c'est normal, que le MTU IPv4 sous windows n'est pas de 1500, mais donc ici de 1474. Pas de diffréence de comportement avec linux.

D'autre part, dans le traceroute, on passe aussi par l'adresse IPv4 194.149.164.0, comme à Castelnau, ce qui montre que cela ne dépend pas de l'emplacement, et que c'est probablement l'adresse IPv4 de sortie  du tunnel IPv6, et que c'est toujours le même routeur final qui est utilisé.
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: Slothy le 28 février 2016 à 20:47:47
Exact pour le MTU en IPv6, j'ai été un peu vite ;)
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: alain_p le 28 février 2016 à 20:49:48
Je viens de revoir que cyberjuls avait bien fait des tests en IPv6, et obtenait aussi un PMTU de 1500 :

https://lafibre.info/free-la-fibre/installation-freebox-revolution-optique-avec-convertisseur/msg283960/#msg283960
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: alain_p le 28 février 2016 à 21:12:10
Je n'avais pas fait attention aux remarques que tu as faites, concernant le FTP de testdebit que tu n'as pas pu contacter, tu as essayé avec quel logiciel, Filzilla ? C'est peut-être une histoire de FTP passif vs actif ? En passif, les ports d’échange des données sont ouverts sur le serveur, donc cela ne devrait pas avoir d'importance le port d'où tu pars, à condition que le serveur testdebit le permette (ou son pare-feu) ?

P.S 2 : je remarque dans ta capture d'écran que le FTP passe bien en passif, mais pas de réponse du serveur.

Pour le VPN, c'est encore à priori un problème d'authentification de l'adresse de la freebox, en 91.160.13.x, qui n'est là non plus pas autorisée. Pour l'interface de gestion, il faut voir si elle va s'actualiser dans les jours à venir.

P.S : c'est étonnant que tu dises que le débit IPv6 est ridicule, surtout vu le test de débit que tu affiches, 720 Mb/s en download, 325 en upload. Normalement le débit en IPv6, natif, devrait être supérieur à celui en IPv4, encapsulé, à moins que le serveur ne soit pas en IPv6 ?
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: vivien le 28 février 2016 à 21:18:42
Le SpeedTest de Massy est normalement réalisé en IPv6, si IPv6 est disponible. (il faudrait une capture wireshark pour confirmer)

Sinon vous pouvez utiliser nperf qui permet de faire un test IPv4 et un test IPv6 sur le serveur de Massy.

Serait-il possible de donner les MSS en IPv4 et en IPv6 ?

Je donne quelques exemples ici avec SFR en IPv4 et IPv6 : Négociation MTU MSS: comment ça fonctionne? (https://lafibre.info/tcpip/negociation-mtu-comment-ca-fonctionne/12/)
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: Slothy le 28 février 2016 à 21:31:02
Effectivement, Massy fonctionne en IPv6, par contre le Speedtest a été effectué en IPv4, car par défaut l'IPv6 n'était pas activé.

Oui, j'ai essayé avec Filezilla, et on voit bien "Entering passive Mode" avant que ça bloque donc il a tenté en passif.

Pour le VPN IKEv2, il y a les port 500 et 4500 qui doivent être disponibles aussi pour que ça fonctionne, et le 1723 en PPTP et vu que je n'ai pas droit à ces ports la...

Pour le débit en IPv6 en tout cas il semblait y avoir une limitation à ~9 Mb/s / thread, confirmé par les téléchargements FTP simultanés sur 1.testdebit.info et le test de neutralité. Maintenant, c'est vrai qu'il aurait été intéressant de tester un autre serveur en IPv6, car les différents tests ont visé la même destination.

Pour les tests de MSS je vais pas pouvoir prochainement, désolé ;D
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: corrector le 28 février 2016 à 21:48:12
La consequence d'utiliser du 4rd donc du partage d'header entre IP4 et IPv6 a des conséquences sur un traceroute en IPv4: celui ci affiche les nœuds IPv6 intermédiaires en IPv4 (adresse bidon)...contrairement a un vrai tunnel qui masque les nœuds intermédiaires.
Comme du NAT!
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: minidou le 28 février 2016 à 21:49:05
Je vois aussi que l'adresse 192.0.2.1 apparait dans le traceroute. Or le bloc 192.0.2.0/24 est réservé par IANA pour des documentations :

http://tools.ietf.org/html/rfc5737#section-3

Il est possible que Free ait ré-utilisé dans son implèmentation des adresses vues dans une documentation, et réservées pour cela...
c'est étrange étant donné qu'il y a une plage d'adresse réservé à cette utilisation spécifique
https://isc.sans.edu/diary/RFC+6598+-+Carrier+Grade+NAT/20777
https://tools.ietf.org/html/rfc6598
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: vivien le 28 février 2016 à 21:58:02
Pour le débit en IPv6 en tout cas il semblait y avoir une limitation à ~9 Mb/s / thread, confirmé par les téléchargements FTP simultanés sur 1.testdebit.info et le test de neutralité. Maintenant, c'est vrai qu'il aurait été intéressant de tester un autre serveur en IPv6, car les différents tests ont visé la même destination.

Voici d'autres serveurs, dispo sur https://testdebit.info/ Online, OVH, ... il y a du choix.

et même l'hébergeur ikoula : remplace le "1" de 1.testdebit.info par "ikoula"
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: alain_p le 28 février 2016 à 22:12:33
Vivien, Slotthy a fait les tests chez un voisin qui vient juste d'avoir la fibre en ZMD, donc il n'a peut-être pas la possibilité d'y retourner de sitôt...
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: corrector le 28 février 2016 à 22:30:33
Le fait de découper les paquets et les reconstituer à l'autre bout génère une forte charge CPU sur les routeurs qui font ce travail.
Et surtout cela demande de stocker un temps indéfini les fragments qui arrivent, avec un timeout "raisonnable", on arrive à un charge mémoire maximum énorme.

En pratique les paquets arrivent plutôt rapidement et proche les uns des autres, mais ça permet de faire une attaque DOS très facilement ce qui va au moins forcer des purges mémoires plus fréquentes (au pire saturer toutes la mémoire et faire bugger la passerelle) et rendre la défragmentation moins efficace.

C'est un défaut générique de la fragmentation IP. Le fait que ce soit une passerelle au cœur du réseau ne ferait qu'empirer le problème.

Un autre problème de la fragmentation IP est pour les NAPT : il faut défragmenter pour avoir les paquets TCP/UDP/... complets afin de faire correspondre chaque paquet à une règle de NAT.

De même de façon plus générale, c'est le cas dès qu'on veut faire du suivi de connexions (conntrack sous linux) : l'activation de conntrack active la défragmentation de tous les paquets automatiquement.

De même de façon encore plus générale, quand on veut appliquer un filtre sur les ports dans le pare-feu. Mais là on peut éventuellement tolérer que les fragments supplèmentaires ne soient pas filtrés, vu qu'ils ne seront jamais complétés si le premier paquet est rejeté.

Cela génère aussi de la gigue, les petits paquets qui ne nécessitent pas d'être découpés arrivent avant les plus gros qui sont passé par l'étape fragmentation / reconstitution.
Pas forcèment.

Les gros paquets n'arrivent pas après les petits en Wifi, que je sache.
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: hwti le 29 février 2016 à 01:03:57
Il y a quelque chose de bizarre dans le test de MTU de Slothy : normalement le ping trop gros devrait sortir "Le paquet doit être fragmenté mais paramétré DF.".
Peut-être que la Freebox ne répond pas, au lieu d'envoyer un ICMP type 3 (Destination Unreachable) code 4 (fragmentation needed and DF set).
Si c'est le cas, ça pourrait expliquer les problèmes sous Linux en IPv4 (https://tools.ietf.org/html/rfc2923), si la Freebox n'ajuste pas le MSS non plus.
Peut-être que Windows détecte ce genre de situations et désactive le PMTU Discovery (et donc ne positionne plus DF sur les paquets de la connexion TCP), ce qui fait que ça fonctionne, mais en fragmentant.
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: kgersen le 29 février 2016 à 14:50:21
la sous-discussion sur FTP est déplacée ici: https://lafibre.info/tcpip/partage-de-ports-mode-de-fonctionnement-de-ftp/
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: corey le 01 mars 2016 à 10:22:40
Bon, voici les résultats des tests réalisés sur la connexion Free de mon voisin.

Machine utilisée : DELL Precision M6600, i7 quadri coeur, 8 Gb de RAM et SSD connectée en direct en câble à la Freebox.

Speedtest :

(https://www.speedtest.net/result/5124828398.png)

-Le débit IPv6 est ridicule, de ce fait je n'ai pas pu terminer le test de neutralité

-Le débit du Speedtest est bien limité par la connexion et non le PC, qui fait 950 Mb/s en FTTH SFR.

Avec un PC (Windows 7 et Firefox) moins performant j'ai les mêmes résultats que toi.
Quel OS et navigateur utilises tu?
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: Slothy le 01 mars 2016 à 15:58:23
Windows 10 et Firefox.
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: didjee34 le 01 mars 2016 à 17:24:06
Hello,

Je n'ai pas eut le temps ce week end de m'y remettre, mais concernant sous Linux le Path MTU Discovery, il faut je pense tester ça :

TCP MTU Probing

0 = disabled
1 = enabled when a black hole router is detected
2 = always enabled

# Enable TCP MTU probing to deal with black hole routers:
echo 2 > /proc/sys/net/ipv4/tcp_mtu_probing
echo 1024 > /proc/sys/net/ipv4/tcp_base_mss

Je vais essayer de faire un test de mise en place d'un tunnel OpenVPN full IPV6 dans la semaine + retester la freebox en bridge sur mon ERLite avec mtu 1472 et avec MTU 1500 + PMTU Discovery

Didier
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: serge.31 le 20 mars 2016 à 18:00:08
ai-je raté quelque chose ???

Un scan exhaustif en 91.160.x.y ne détecte aucune freebox.
J'ai vérifié qu'il y a des utilisateurs en ip v6 ZMD dont la conversion en v4 s'effectue sur la plage 1/4 des ports (celle qui répond au ping)

le ping serait-il bloqué par free en 91.160 ?

Merci
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: s3phy le 20 mars 2016 à 18:27:42
Laquelle des 4 boxes derrière l'IPv4 doit répondre ?
Ou alors est-ce que c'est l'infra 4rd qui doit répondre ?

Dans les deux cas ça n'avance pas à grand chose que ça réponde, de mon point de vue !
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: alain_p le 20 mars 2016 à 18:36:29
En plus, l'IPv4 est transportée dans une trame IPv6 (4rd). Vivien avait vu qu'un traceroute sur ces adresses s'arrêtait à l'entrée du tunnel, un routeur à Courbevoie. Donc un scan sur les adresses 91.160 ne mène à rien.
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: serge.31 le 20 mars 2016 à 23:28:37
OK
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: Nico le 21 mars 2016 à 07:52:31
un routeur à Courbevoie
Bezons plutôt ?
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: alain_p le 21 mars 2016 à 08:13:03
Bezons plutôt ?

Il me semblait que Vivien avait parlé de Courbevoie, et je viens de vérifier, c'est le cas :

Citer
Le dernier routeur est "cbv-crs8-1.intf.routers.proxad.net" donc un gros Cisco CRS localisé sur Courbevoie (92).

https://lafibre.info/free-10g-epon/cgn-14-chez-free-une-ipv4-partagee-par-4-clients/msg283323/#msg283323
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: serge.31 le 21 mars 2016 à 17:40:53
un traceroute vers une ip en ZMD :

L:\>tracert 91.160.5.1
Détermination de l'itinéraire vers 91-160-5-1.subs.proxad.net [91.160.5.1] avec un maximum de 30 sauts :
  1    <1 ms    <1 ms    <1 ms  Freebox_Serge.31_LAN [192.168.0.254]
  2     5 ms     5 ms     7 ms  sto31-1_gw [78.213.148.254]
  3    21 ms    12 ms     6 ms  toulouse-x-routers [213.228.9.254]
  4     7 ms    21 ms    14 ms  toulouse-crs8-2-be1006.intf.routers.proxad.net [194.149.160.69]
  5    17 ms    25 ms    22 ms  bzn-crs16-2-be1119.intf.routers.proxad.net [194.149.163.25]
  6    16 ms    36 ms    16 ms  bzn-crs16-2-be1005.routers.proxad.net [78.254.249.77]
  7     *        *        *     Délai d'attente de la demande dépassé.

le dernier vu est bzn-crs16-2-be1005.routers.proxad.net ... ce qui pourrait expliquer cette différence.
D'autres traceroute pour vérifier ?
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: s3phy le 21 mars 2016 à 19:37:28
Depuis une Bbox en Gironde :
                                   My traceroute  [v0.85]
kirino (0.0.0.0)                                                   Mon Mar 21 19:37:09 2016
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                                   Packets               Pings
 Host                                            Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 192.168.1.254                                 0.0%   100    0.4   0.4   0.4   0.8   0.0
 2. bft33-h01-176-146-77-126.dsl.sta.abo.bbox.fr  0.0%   100   21.9  24.2  20.5  72.4   6.5
 3. 51.la63.bsr01-bdx.net.bbox.fr                 0.0%   100   21.8  36.9  21.0 834.8 102.7
 4. be65.cbr01-poi.net.bbox.fr                    0.0%   100   27.8  26.3  23.9  29.1   1.1
 5. be5.cbr01-ntr.net.bbox.fr                     0.0%   100   30.4  33.1  27.9 167.3  13.8
 6. la42.rpt06-th2.net.bbox.fr                   82.8%   100   29.3  28.9  28.3  29.7   0.0
 7. ???
 8. p11-crs16-1-be1001.intf.routers.proxad.net    0.0%   100   32.0  31.5  28.7  72.0   4.2
 9. cbv-crs8-1.intf.routers.proxad.net            0.0%   100   29.9  29.7  28.8  52.9   2.3
10. ???
On peut supposer que le hop n°10 ici c'est l'infra 4rd, qui ne réponds pas au ping, et qu'elle est accessible directement depuis différents routeurs sur le réseau de Free ? Ce qui explique comment le dernier hop que tu vois est à Bezons, et moi à Courbevoie.
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: alain_p le 21 mars 2016 à 19:45:41
Je suis sur le réseau Free, et j'ai :

$  mtr -rwc100 91.160.5.1
Start: Mon Mar 21 19:39:10 2016
HOST: ubuntu-srv                                 Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.168.0.254                               0.0%   100   26.9  18.4   1.8  72.1  18.9
  2.|-- arp91-4-78-235-182-254.fbx.proxad.net       0.0%   100   65.1  32.0   6.5  91.1  23.5
  3.|-- 213.228.23.254                              0.0%   100   18.6  25.4   7.1  77.9  20.1
  4.|-- p11-crs16-1-be1114.intf.routers.proxad.net  0.0%   100   28.5  32.4   8.5  85.9  21.7
  5.|-- cbv-crs8-1.intf.routers.proxad.net          0.0%   100   63.2  29.8   8.0  71.5  19.5
  6.|-- ???                                        100.0   100    0.0   0.0   0.0   0.0   0.0

$ traceroute 91.160.5.1
traceroute to 91.160.5.1 (91.160.5.1), 30 hops max, 60 byte packets
 1  192.168.0.254 (192.168.0.254)  30.677 ms  30.680 ms  30.668 ms
 2  arp91-4-78-235-182-254.fbx.proxad.net (78.235.182.254)  30.661 ms  30.653 ms  30.596 ms
 3  213.228.23.254 (213.228.23.254)  30.543 ms  30.507 ms  30.473 ms
 4  p11-crs16-1-be1114.intf.routers.proxad.net (194.149.162.145)  45.696 ms  45.638 ms  45.629 ms
 5  cbv-crs8-1.intf.routers.proxad.net (78.254.249.102)  30.332 ms  30.526 ms  30.488 ms
 6  * * *

Dans les deux cas, j'arrive jusqu'au routeur à Courbevoie.
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: Slothy le 21 mars 2016 à 19:47:42
Chez moi l'IP est même pas routée, wtf

Target Name: 91-160-5-1.subs.proxad.net
         IP: 91.160.5.1
  Date/Time: 21/03/2016 19:46:11 to 21/03/2016 19:46:50

Hop Sent Err   PL% Min Max Avg  Host Name / [IP]
 1    11   0   0,0   0   0   0  rb1100.gw [172.16.0.254]
 2    11   0   0,0   0   2   0  94cpy1-nro-1.nro.gaoland.net [109.24.76.32]
 3    11   0   0,0   1 154  26  37.142.24.109.rev.sfr.net [109.24.142.37]
 4    10  10 100,0   0   0   0   [-]
[...]

Destination not reached in 35 hops
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: alain_p le 21 mars 2016 à 20:16:39
Parce que les routes vers ces adresses n'ont pas été annoncées sur les routeurs SFR ?
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: Nico le 21 mars 2016 à 20:19:19
Si ?

nico@debian2-vm:~$ mtr -rwc10 91.160.5.1
Start: Mon Mar 21 20:18:51 2016
HOST: debian2-vm                                 Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- box                                         0.0%    10    0.5   0.5   0.4   0.6   0.0
  2.|-- 75tip1-nro-1.nro.gaoland.net                0.0%    10    1.7   2.5   0.8   4.9   1.1
  3.|-- 21.48.20.93.rev.sfr.net                     0.0%    10    1.7   3.3   1.4   6.1   1.5
  4.|-- 90.116.3.109.rev.sfr.net                    0.0%    10    4.0   5.0   3.1   7.6   1.8
  5.|-- ???                                        100.0    10    0.0   0.0   0.0   0.0   0.0
  6.|-- p11-crs16-1-be1000.intf.routers.proxad.net  0.0%    10    9.4   6.2   4.7   9.4   1.8
  7.|-- cbv-crs8-1.intf.routers.proxad.net          0.0%    10    5.1   4.5   2.1   7.3   1.4
  8.|-- ???                                        100.0    10    0.0   0.0   0.0   0.0   0.0


Mais j'en conviens, un traceroute ne fonctionne pas.
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: Slothy le 21 mars 2016 à 20:30:20
En fait ça marche depuis une autre machine donc ça vient pas de la connexion, vraiment bizarre car j'arrive bien sur le réseau de SFR. Sinon la fin du traceroute est identique à celui de Nico.
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: serge.31 le 22 mars 2016 à 14:08:00
je suis le seul à terminer sur bzn-crs16-2-be1005.routers.proxad.net [78.254.249.77] ?
depuis une connexion dégroupée chez Free.
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: klim94 le 22 mars 2016 à 14:27:22
je suis le seul à terminer sur bzn-crs16-2-be1005.routers.proxad.net [78.254.249.77] ?
Testé depuis plusieurs connexions dégroupées Free et je tombe sur cbv ; idem depuis dédibox.

Par contre depuis serveur dédié chez OVH je tombe aussi sur bzn

Détermination de l'itinéraire vers 91-160-5-1.subs.proxad.net [91.160.5.1]
avec un maximum de 30 sauts :

  1     1 ms     1 ms     1 ms  rbx1-3a-a9.fr.eu [91.121.122.252]
  2     1 ms     3 ms     2 ms  be11-149.rbx-g2-a9.fr.eu [37.187.231.67]
  3     4 ms     4 ms     4 ms  be99-1181.gsw-1-a9.fr.eu [213.251.130.55]
  4     *        *        *     Délai d'attente de la demande dépassé.
  5    11 ms     7 ms     7 ms  bzn-crs16-2-be1013.intf.routers.proxad.net [194.
149.163.157]
  6     4 ms     4 ms     4 ms  bzn-crs16-2-be1005.routers.proxad.net [78.254.24
9.77]
  7     *        *        *     Délai d'attente de la demande dépassé.
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: serge.31 le 22 mars 2016 à 19:48:09
je me sens moins seul  :P
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: Darklight le 22 mars 2016 à 19:59:03
Sur une ligne non dégroupée Free vers 91.160.5.1 :
1  192.168.254.254 (192.168.254.254)  20.148 ms  19.728 ms  20.673 ms
 2  bzn-6k-5-v201.routers.proxad.net (212.27.55.126)  21.188 ms * *
 3  p11-9k-1-be1026.intf.routers.proxad.net (212.27.57.126)  21.640 ms  21.138 ms  21.666 ms
 4  p11-crs16-1-be1008.intf.routers.proxad.net (194.149.163.53)  22.164 ms  23.959 ms  23.357 ms
 5  cbv-crs8-1.intf.routers.proxad.net (78.254.249.102)  20.722 ms  21.390 ms  20.514 ms
 6  * * *
 7  * * *
 8  * * *
Pas beaucoup de sauts et je tombe sur cbv et non bzn. Je fais le test directement depuis mon routeur, le premier saut c'est le DSLAM.
Titre: FTTH ZMD: Free fait du DS-Lite
Posté par: tindav le 28 mars 2016 à 10:31:11
L'IP dédiée, Rani a dit que l'option serait gratuite, et que l'on pourrait même avoir plusieurs IP (option payante). Mais on attend toujours sa réponse sur la date de disponibilité de l'option...

Pour moi, en ZMD, c'est toujours en beta-test. Mais chez Free, on l'a souvent vu (freebox v6, 4K etc...), on peut être en beta-test et en même temps en étape de commercialisation. Il vaut mieux attendre que les soucis soient réglés avant de souscrire...

P.S : au fait, tu as quel range de ports ?

Je suis désolé si cela a déjà été dit sur ce thread, mais est ce que la procédure pour demander une IP dédiée est déjà existante et si oui, quelle est t'elle ?
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: eruditus le 28 mars 2016 à 10:33:38
La réponse est, non, elle n'existe pas encore.
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: tindav le 28 mars 2016 à 10:39:25
La réponse est, non, elle n'existe pas encore.

Merci pour ta réponse rapide
Ma migration vers la fibre est prévue pour le 21 avril et, pas de bol, ma plage de port est prévue sur 49152-65535 ...
je pourrais m'y faire si besoin, mais une dédiée serait quand même plus cool ...
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: underground78 le 28 mars 2016 à 10:41:25
Comment as-tu trouvé ta plage de ports avant d'être raccordé ?
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: Paul le 28 mars 2016 à 10:59:36
Tu peux voir ton adresse IP et ta plage de port avant d'avoir reçu ta box, dès que ton espace client est activé, dans Ma Freebox > Afficher mon adresse IP.
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: alain_p le 28 mars 2016 à 16:29:12
Oui, le SI de Free s'améliore dans le support des ZMDs. Ces informations ne figuraient pas avant. D'autres ont eu pendant quelque temps leur ancienne IP xDSL.

On attend aussi la concrétisation de la promesse de Rani sur l'IP complète...
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: Paul le 28 mars 2016 à 18:23:53
D'autres ont eu pendant quelque temps leur ancienne IP xDSL.

Sur une connexion fibre ? :o
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: Slothy le 28 mars 2016 à 18:28:32
Non, l'interface était juste pas mise à jour.
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: agaucher le 26 avril 2016 à 15:50:06
Bonjour,

Pour ma part, je suis client Free (Fibre) et je suis passé sur ces fameuses IP partagées.
On m'a assigné les ports de 0 à 16383, et ils sont en effet utilisables par les logiciels qui initient des connexions vers l'extérieur.
Mais sauf erreur de ma part, seul le port 80 est joignable depuis l'extérieur.

j'ai en effet essayé de monter un serveur IIS, et ma page web n'est accessible que quand IIS est bindé sur le port 80.
Cela ne semble pas fonctionner avec les autres ports.

Probablement à cause de ça, ma femtocell Orange, branchée en Ethernet sur ma Freebox, ne fonctionne plus sur la ligne Fibre.
Elle nécessite l'ouverture de différents ports (500 UDP, 4500 UDP...) et je pense que l'IP partagée bloque cette fonctionnalité.
Si quelqu'un a une solution (autre que IPv6 car la femtocell n'est pas compatible), je suis preneur. Autrement, j'envisage de changer d'opérateur.

Pour la hotline Free, tout est normal, du moment que la navigation internet fonctionne....

Cordialement,
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: Nico le 26 avril 2016 à 15:53:49
Autrement, j'envisage de changer d'opérateur.
Mobile ou fixe ?
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: underground78 le 26 avril 2016 à 15:57:22
Fixe je suppose.

Par contre je ne comprends pas trop, tu testes quoi exactement ? Ouvrir un port P sur la Freebox et le rediriger vers ton serveur web qui est configuré pour écouter sur ce fameux port P ?
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: agaucher le 26 avril 2016 à 16:14:16
Oui pardon, je n'ai pas été très clair.
Si je ne règle pas mon problème de Femtocell, je choisirais un autre opérateur Internet.

@Underground78 : c'est exactement ça. la Freebox est configurée pour rediriger les paquets venant de l'extérieur vers mon serveur IIS. Lorsque tout est configuré avec le port 80, ça fonctionne bien. Mais si je prend le port 81 par exemple, alors le site n'est accessible que depuis le réseau local. Je ne crois pas m'être trompé dans une configuration quelconque.

Mon problème de fond est que ma femtocell Orange n'arrive pas à se connecter aux serveurs Orange et c'est très probablement lié à cette IP partagée. Durant une semaine, j'avais les deux lignes ADSL et FIBRE en même temps, et la femtocell fonctionnait correctement en ADSL (IP complète) mais ne fonctionnait pas en FIBRE (IP partagée).

Je crois que la solution choisie par Free rend incompatible certains équipements.
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: underground78 le 26 avril 2016 à 16:19:33
C'est quand même super bizarre, il me semble que des abonnés en ZMD arrivaient bien à rediriger les ports qui leur appartiennent. Il faudrait creuser la chose, si ce que tu dis se confirme, j'aurais tendance à penser que ce n'est pas le comportement attendu.
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: Darkjeje le 26 avril 2016 à 16:22:40
Peux-tu poster une capture écran des redirections de ports que tu as paramétré sur la freebox serveur ?
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: tindav le 26 avril 2016 à 16:53:20
C'est quand même super bizarre, il me semble que des abonnés en ZMD arrivaient bien à rediriger les ports qui leur appartiennent. Il faudrait creuser la chose, si ce que tu dis se confirme, j'aurais tendance à penser que ce n'est pas le comportement attendu.

Je confirme.

Pas de soucis de mon coté pour rediriger ma super plage de port (49000 => 65000) vers mes machines
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: Snickerss le 26 avril 2016 à 17:35:08
Cela ne résout pas le problème de la femtocell tu me diras :/
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: PacOrly le 26 avril 2016 à 17:46:37
Tes tests sont depuis ton LAN ou depuis l'extérieur (pb loopback)?
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: underground78 le 26 avril 2016 à 17:50:56
Dommage que rani ne passe plus par ici sinon ça serait un bon cas pratique à lui soumettre.
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: agaucher le 26 avril 2016 à 19:38:25
Bonjour,

Merci à vous tous pour votre implication !

Alors suite au commentaire de Tindav, j'ai double checké. Et au final, je me suis aperçu que c'était le pare feu windows qui me jouait des tours (port 80 ouvert, port 81 fermé, mais 81 en IPv6 fonctionne.... ?).
Donc au final l'erreur venait de moi, les ports sont bien accessibles depuis l'extérieur.

Du coup pour la femtocell, je vais chercher un peu car ça ne doit pas être lié à l'IP partagée, il doit y avoir une autre explication.
J'ai ouvert les ports UDP-4500, UDP-500, UDP-2746, TCP/UDP-123, mais peut être que ce n'est pas suffisant.

Merci à tous, vous m'avez bien aidé en tout cas.
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: agaucher le 26 avril 2016 à 20:19:23
Après avoir regardé en détails les protocols/ports utilisés par la femtocell, je vois qu'elle créée un tunnel IpSec et qu'elle a besoin des ports suivants :

IP-50 (ESP)
IP-51 (AH)
IP-57 (SKIP)
UDP-4500
UDP-500
UDP-2746
TCP/UDP-123(NTP)

Est-ce que la création du tunnel IpSec pourrait être incompatible avec l'IP mutualisée ?
Je ne connais pas du tout et la littérature sur le sujet est assez complexe :(
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: Marin le 26 avril 2016 à 20:40:38
C'est tout à fait possible également.
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: agaucher le 26 avril 2016 à 20:58:49
Je pense qu'il y a bien une incompatibilité entre IpSec et les IP partagées de Free :(

RFC 6346: The Address plus Port (A+P) Approach to the IPv4 Address Shortage
Citer
5.3.4.  Limitations of the A+P Approach
[...]
Another problem that is common to all NATs is coexistence with IPsec.
In fact, a NAT that also translates port numbers prevents the
Authentication Header (AH) and Encapsulating Security Payload (ESP)
from functioning properly, both in tunnel and in transport mode.  In
this respect, we stress that, since an A+P subsystem exhibits the
same external behavior as a NAT, well-known workarounds (such as
[RFC3715]) can be employed.
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: underground78 le 26 avril 2016 à 21:00:37
Ça serait le moment d'invoquer Rani pour voir ce qu'il a proposé (au pire dans combien de temps arrive l'option "IP non partagée").
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: Snickerss le 27 avril 2016 à 11:46:29
Ça serait le moment d'invoquer Rani pour voir ce qu'il a proposé (au pire dans combien de temps arrive l'option "IP non partagée").


Y'a rien à corriger. Orange doit passer ses femto sur IPv6, ou l'abonné doit prendre un FAI qui offre une connectivité complète en IPv4 sans ce mécanisme. (en attendant la fameuse option de Free ..?)
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: underground78 le 27 avril 2016 à 14:50:19
J'ai pas dit "corriger", j'ai dit "proposer". Comprendre que je pense qu'il serait intéressant d'avoir des nouvelles de la fameuse option par la personne qui l'a annoncée.
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: alain_p le 27 avril 2016 à 15:57:31
Cela fait près de deux mois et demi qu'il a dit que cette option allait arriver "bientôt" (c''était le 13 Février).

https://lafibre.info/free-10g-epon/cgn-14-chez-free-une-ipv4-partagee-par-4-clients/msg307247/#msg307247
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: willemijns le 29 avril 2016 à 21:04:38
Ça serait le moment d'invoquer Rani pour voir ce qu'il a proposé (au pire dans combien de temps arrive l'option "IP non partagée").

A force je sais plus si on connait vraiment l'intérêt officiel de la chose, du "radiniel" ?
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: corrector le 30 avril 2016 à 17:57:38
Après avoir regardé en détails les protocols/ports utilisés par la femtocell, je vois qu'elle créée un tunnel IpSec et qu'elle a besoin des ports suivants :

IP-50 (ESP)
IP-51 (AH)
IP-57 (SKIP)
IP-x ne désigne pas un numéro de port!
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: alain_p le 30 avril 2016 à 19:05:37
Oui, ce sont des numéros de protocole, comme ICMP peut en être un, mais il faut aussi expliquer...

Voir par exemple (en anglais) :
http://www.linuxquestions.org/questions/linux-networking-3/what-is-protocol-50-a-375085/
https://en.wikipedia.org/wiki/List_of_IP_protocol_numbers
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: corrector le 30 avril 2016 à 20:16:11
Oui, ce sont des numéros de protocole, comme ICMP peut en être un, mais il faut aussi expliquer...

Voir par exemple (en anglais) :
http://www.linuxquestions.org/questions/linux-networking-3/what-is-protocol-50-a-375085/
https://en.wikipedia.org/wiki/List_of_IP_protocol_numbers
On ne peut donc pas les diviser comme on divise les ports.
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: trekker92 le 31 mai 2016 à 14:14:31
Cela fait près de deux mois et demi qu'il a dit que cette option allait arriver "bientôt" (c''était le 13 Février).

quand on convertit le bientot en échelle temporelle Free ca peut donner bien des mois (en années)
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: alain_p le 31 mai 2016 à 18:09:49
Bon, l'échelle temporelle de Free du "bientôt", c'est effectivement des mois, voire plus d'une année. Mais par expérience (le cas de la fibre est peut-être moins optimiste...), cela finit pas arriver. Alors on va espérer et patienter (facile pour moi, je suis en zone AMII Orange, où le déploiement devait commencer en 2015, mais toujours pas de fibre...).
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: rani le 11 juin 2016 à 19:33:55
Cela fait près de deux mois et demi qu'il a dit que cette option allait arriver "bientôt" (c''était le 13 Février).

https://lafibre.info/free-10g-epon/cgn-14-chez-free-une-ipv4-partagee-par-4-clients/msg307247/#msg307247

Ce sera dispo à partir de la semaine prochaine.
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: alain_p le 11 juin 2016 à 19:58:09
Merci Rani pour l'info. Enfin ! Cela manquait à l'offre en ZMD.
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: Chris_tou le 11 juin 2016 à 20:29:05
Ce sera dispo à partir de la semaine prochaine.


Merci Rani, c'est cool de nous tenir au courant  8)
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: spectrolazer le 11 juin 2016 à 20:34:48
Merci Rani pour l'info. Enfin ! Cela manquait à l'offre en ZMD.
Ce qui manque aussi c'est l'offre en ZMD SFR et ce sera pas la semaine prochaine ;) hein Rani :)
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: alain_p le 11 juin 2016 à 20:49:15
C'est sûr que pour les ZMDs SFR, cela risque de ne pas être la semaine prochaine. Il faudra déjà que Free décide d'une solution pour loger ses switchs ZMD, puis tirer ses fibres jusqu'aux PM.... Pourra-t-il comme dans les zones Orange utiliser les NRA/NROs Orange ? Utiliser ceux de SFR ? Installer ses propres NROs ?
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: underground78 le 12 juin 2016 à 09:57:43
Bonne nouvelle en tout cas, peut-être que ça va arriver avec une certaine normalisation de la communication autour des ZMD (notamment sur le site de l'assistance Free) ?
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: ifranz67 le 13 juin 2016 à 10:36:55
Ce sera dispo à partir de la semaine prochaine.

Merci pour l'info :) En ZTD aussi possibilité d'avoir plusieurs IP ?
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: Snickerss le 13 juin 2016 à 10:57:09
Merci pour l'info :) En ZTD aussi possibilité d'avoir plusieurs IP ?

A mon avis cela va ensemble. Le mécanisme est le meme, donc si l'un existe, lautre est forcèment pas loin
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: docmarc le 13 juin 2016 à 12:38:08
Ce sera dispo à partir de la semaine prochaine.

C'est bien de dire qu'une option seras disponible ( mème si c'est cacher dans un forum  )

Ce serais encore mieux ce serais d'avoir une carte de reploiement ZMD FTTH avec des dates ( on est pas au trimestre près ! )

exemple a Vannes (56) je ne voit toujours pas  de FttH en vue (aucune date ?)  ( ni de 4G qui couvre mon quartier de la madeleine - AV de la marne )

Orange le fait bien ? pourquoi pas FREE ?

Je n'ose pas croire les rumeurs qui dit que les déploiements FREE sont fait au "FEELING" , et qu'il n'y a aucun plan réel en vue ??
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: underground78 le 13 juin 2016 à 13:36:25
Surtout qu'ici on parle de la technologie 4rd utilisée par Free en ZMD (et probablement dans les nouvelles ZTD) pour faire de l'IPv4 par dessus IPv6. :)
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: didjee34 le 13 juin 2016 à 15:31:05
Ce sera dispo à partir de la semaine prochaine.

Je me met à rêver en lisant ton annonce Rani !

Est-ce que je vais pouvoir ressortir de son placard mon Ubiquity ERLite, et pouvoir profiter d'un uplink sans setter une MTU à 1472 ? (avec comme conséquence une limitation des débits drastiques avec un OpenVPN par exemple + instabilités).

Est-ce que le fait de prendre l'option "IP Fixe" nous permet de sortir de cette architecture avec NAT + MTU abusive ou en fait on reste dans cette infra, avec "juste" le confort de toutes les plages de port 0-65535 disponibles ?

Cordialement,

Didier
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: underground78 le 13 juin 2016 à 15:48:54
Je ne pense pas que la MTU change puisque la technologique utilisée reste la même. Par contre je croyais que Free utilisait des "jumbo frames" justement pour conserver la MTU identique ?

Edit : J'ai retrouvé le message en question : https://lafibre.info/free-10g-epon/port-443-non-accessible-sur-free-ftth/msg314899/#msg314899
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: kgersen le 13 juin 2016 à 16:06:06
Je me met à rêver en lisant ton annonce Rani !

Est-ce que je vais pouvoir ressortir de son placard mon Ubiquity ERLite, et pouvoir profiter d'un uplink sans setter une MTU à 1472 ? (avec comme conséquence une limitation des débits drastiques avec un OpenVPN par exemple + instabilités).

Est-ce que le fait de prendre l'option "IP Fixe" nous permet de sortir de cette architecture avec NAT + MTU abusive ou en fait on reste dans cette infra, avec "juste" le confort de toutes les plages de port 0-65535 disponibles ?

Cordialement,

Didier

c'est la meme techno et le MTU est a 1500 grace au jumbo frames.

apres en quoi est-ce une architecture abusive ? autant le partage d'une IPv4 pour 4 est discutable, autant le 4rd avec une IP full ne l'est pas (si le débit est maximum en IPv4 bien sur).
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: didjee34 le 13 juin 2016 à 16:39:08
c'est la meme techno et le MTU est a 1500 grace au jumbo frames.

apres en quoi est-ce une architecture abusive ? autant le partage d'une IPv4 pour 4 est discutable, autant le 4rd avec une IP full ne l'est pas (si le débit est maximum en IPv4 bien sur).

En fait, je n'avais pas vu l'activité depuis courant Février :

En ZMD, la mtu es à 1500 que ça soit en v4 ou en v6. On supporte les jumbo.

Rani :
"Par contre, y a un soucis (lire bug) sur certains ONU qui prennent pas correctement leur conf pour
accepter les jumbo  qui est apparu suite à une modif mi-février (ce qui pose donc des pbs en v4).
Y a eu une correction la nuit dernière mais on voit encore quelques cas => on va voir avec le constructeur."

Je confirme que depuis début Mars je n'ai pas retenté de passer la MTU a 1500, mais qu'après de nombreux tests la seule façon d'avoir une connectivité (ping, OpenVPN, traceroute, etc), c'était bel et bien de passer la MTU a 1472.

Si le "bug" est corrigé, je vais m'empresser de faire un petit test ce soir !

Du coup, merci pour l'information !

Cordialement,

Didier
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: eruditus le 13 juin 2016 à 16:40:37
Et merci d'avance pour le retour ;)
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: eruditus le 13 juin 2016 à 17:31:13

Pour ceux qui veulent continuer le HS, sur le dėploiement, la propriété ou la location, c'est là...
https://lafibre.info/bistro-sujet-libre/ftth-zmd-free-ferait-du-4rd-ipv4-portee-par-ipv6-et-nat-sur-le-reseau/

Prochain(s) message(s) hors sujet 4rd, c'est direct poubelle.
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: Paul le 14 juin 2016 à 22:12:53
Clubic a fait un article (http://www.clubic.com/connexion-internet/fai-free-box-freebox/actualite-808988-freebox-ipv4-dediee-4rd.html) sur l'option IPv4 dédiée en citant lafibre.info :)
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: underground78 le 17 juin 2016 à 15:20:49
Ce sera dispo à partir de la semaine prochaine.
Bon, on a raté la mise en place de l'option ou elle est en retard ?
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: Archange le 17 juin 2016 à 15:29:22
Bonjour,
Idem... Toujours a attendre et à surveiller l'espace client.
J'attends cette possibilité avec impatience car je suis pénalisé avec cette histoire de partage des ports.
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: Hugues le 17 juin 2016 à 15:41:50
Bon, on a raté la mise en place de l'option ou elle est en retard ?

La semaine free ?  8)
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: underground78 le 17 juin 2016 à 15:45:42
Le 8 juin c'était encore un "work in progress" d'après un corp Free sur les newsgroups (http://www.journaldufreenaute.fr/outils/nspy.php?post=44940).
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: Oxynux le 18 juin 2016 à 00:51:35
Avec Free, il faut apprendre à être patient et à ne pas se fier aux ETA annoncées  ;D
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: Hugues le 18 juin 2016 à 01:05:07
On dirait un adolescent quand on l'appelle pour manger, c'est rigolo (et je sais de quoi je parle !)
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: corrector le 18 juin 2016 à 02:57:04
On dirait un adolescent quand on l'appelle pour manger, c'est rigolo (et je sais de quoi je parle !)
Ah ah excellent
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: alain_p le 18 juin 2016 à 08:42:52
Ce sera dispo à partir de la semaine prochaine.

Rani, on n'a rien vu cette semaine. Il y a du retard ?
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: gillejeu le 18 juin 2016 à 23:15:02
Rani, on n'a rien vu cette semaine. Il y a du retard ?

Il viendra le confirmer demain (soit le 14/07/2016)... Et oui, chez Free, le temps a une autre valeur que celle de la rotation de la terre sur son axe...
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: corrector le 18 juin 2016 à 23:21:13
En fait Free se déplace à grande vitesse par rapport à nous, mais alors très très grande la vitesse...
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: Nh3xus le 19 juin 2016 à 01:07:37
On dirait un adolescent quand on l'appelle pour manger, c'est rigolo (et je sais de quoi je parle !)

Dixit l'adolescent hein...  ;D
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: xav-stargate le 19 juin 2016 à 11:59:05
Si c'est en retard de seulement une semaine pour des tests & MeP ça va :D ! C'est pas comme la V7 qui est en retard de X semaines mois années
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: Estivenques le 19 juin 2016 à 13:10:42
En effet, 1 semaine, c'est rien... Si seulement j'avais le choix entre mon IP complète actuelle et la fibre...  ::)
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: Hugues le 19 juin 2016 à 20:05:19
Dixit l'adolescent hein...  ;D


Ben c'est pour ça que je sais de quoi je parle :-)
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: Archange le 20 juin 2016 à 08:36:09
En effet, 1 semaine, c'est rien... Si seulement j'avais le choix entre mon IP complète actuelle et la fibre...  ::)
Il est certain que la Fibre permet des utilisations confortables et avancées.
Cependant lorsque cette dernière te pénalise cela n'est pas très agréable!
Dans mon cas, je ne peux pas accéder à mes serveurs distants (hébergés chez OVH) !
Mais j'ai solutionné provisoirement le truc en passant par un VPN pour me connecter.

il aura aussi fallu que je modifie toutes mes config pour l'accès à distance à mes caméras, à la Freebox et le plus chiant c'est mon serveur de jeux (et de DATA)

Bref... même si la fibre assure une qualité de connexion indéniable, le partage de ports te handicape fortement lorsque tu as une utilisation un peu avancé de ton accès web.
Ce qui, il faut l'avouer, est vraiment un comble!
Avoir la fibre et ne pas pouvoir accéder à des serveurs (sans passer par un VPN) est juste hallucinant!
Est-il utile de rappeler que le principe même d'internet c'est d’accéder rapidement et simplement à des serveurs ?

Seuls ceux qui téléchargent comme des "porcs" se réjouiront d'un tel système puisque la loi autorise la HADOPI à demander des identités en rapport avec des adresses IP mais le texte ne prévoit rien pour les ports.
Dans un tel cas la HADOPI devrait donc recevoir de 1 à 4 noms pour une même A.IP


Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: underground78 le 20 juin 2016 à 08:41:29
Dans mon cas, je ne peux pas accéder à mes serveurs distants (hébergés chez OVH) !
Ça c'est bizarre, comment y accèdes-tu ?
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: Archange le 20 juin 2016 à 08:45:13
Ça c'est bizarre, comment y accèdes-tu ?
AH oui pardon... j'ai oublié de préciser.
Impossible d'accéder à mes serveurs via le FTP (port 21)
Je passe donc par un VPN
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: Hugues le 20 juin 2016 à 09:02:00
1/ FTP en 2016 ? Beurk, SFTP rulez !

2/ Je suis pas étonné, le FTP est un truc très bizarre avec le NAT et ce genre de trucs, je me souviens d'abonnés K-Net qui ont eu des soucis avec ça.
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: Marin le 20 juin 2016 à 09:21:12
Seuls ceux qui téléchargent comme des "porcs" se réjouiront d'un tel système puisque la loi autorise la HADOPI à demander des identités en rapport avec des adresses IP mais le texte ne prévoit rien pour les ports.

Ils ne se réjouiront de rien puisque la Hadopi n'est pas un organisme à but répressif et est loin d'agir de manière effective comme un organisme de répression. Et la substitution de cet identifiant de par l'utilisation d'un réseau privé virtuel est plus triviale que de se soucier de ces considérations techniques.
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: Snickerss le 20 juin 2016 à 09:53:11
1/ FTP en 2016 ? Beurk, SFTP rulez !


Comme beaucoup de choses, ça dépend du besoin :)


Pour un serveur hébergeant des drivers par exemple .. Le FTP est loin d'être mort, et ce n'est pas forcèment une mauvaise chose. C'est ultra simple, basique, et ca marche bien.
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: underground78 le 20 juin 2016 à 09:53:45
Impossible d'accéder à mes serveurs via le FTP (port 21)
Il suffit de régler correctement le mode passif/actif et ça devrait refonctionner.
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: Archange le 20 juin 2016 à 09:55:21
Il suffit de régler correctement le mode passif/actif et ça devrait refonctionner.
J'ai déjà essayer, sans succès (idem pour le SFTP)
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: vivien le 20 juin 2016 à 10:02:15
ca ne marche pas sur ftp://1.testdebit.info ?
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: underground78 le 20 juin 2016 à 10:24:21
Je ne sais plus si c'était sur lafibre.info mais je suis sûr d'avoir déjà discuté de ça avec un abonné Free ZMD et il avait fini par réussir à faire fonctionner FTP en configurant son client.
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: Archange le 20 juin 2016 à 10:24:54

[/quote]
ca ne marche pas sur ftp://1.testdebit.info ?
Pour moi cette question ? Si oui, je ne suis pas chez moi avant fin de journée.
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: AbP le 20 juin 2016 à 16:44:36
Je ne sais plus si c'était sur lafibre.info mais je suis sûr d'avoir déjà discuté de ça avec un abonné Free ZMD et il avait fini par réussir à faire fonctionner FTP en configurant son client.

NewsGroup proxad.free.services.pagesperso   
utilisateur david le 11/03/2016 à 22:51:32 sur le Plessis-Trévise :

"Mon adresse IP est bien partagée avec 3 autres utilisateurs, mais nous avons chacun une plage de ports attribués différente.
La mienne: Ports 0 à 16383
Filezilla permet de paramétrer une plage de port en mode "actif" donc j'ai inséré ma plage de ports
(en fait 1024 - 16383 car Filezilla ne prend pas moins).
En me connectant maintenant en mode "actif" je récupère donc mes accès FTP."

A tester.
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: Archange le 20 juin 2016 à 16:53:20

Je teste ce soir...
Cependant, à partir du moment ou le client à la plage "0/16383" il ne devrait rencontrer de pb
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: underground78 le 20 juin 2016 à 17:12:06
Le problème avec le FTP sortant (en mode client donc) concerne potentiellement tous les utilisateurs avec une IP partagée (en fait ça serait même plutôt les utilisateurs qui ont une plage élevée qui ont le moins de chance d'être affectés).
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: corrector le 21 juin 2016 à 19:14:15
Je ne comprends pas de quel problème tu veux parler!
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: didjee34 le 10 juillet 2016 à 17:23:34
Hello à tous,

Pour info: j'ai basculé en mode Full IPv4 (IP dédiée).

J'ai pris un peu de temps aujourd'hui pour ressortir mon ERLite 3 du placard ! J'en ai profité pour le passer de la version 1.7.0 à la toute dernière 1.8.5.

Alors, il y a effectivement du mieux, genre du beaucoup beaucoup mieux !

J'ai effectivement plus aucun de soucis de MTU sur l'interface WAN en DHCP (en IPv4) avec la Freebox Mini 4K en mode bridge (bug bien fixé du coup). Que cela soit en MTU 1472/1480/1500/9000 ça passe et j'ai tout le temps l'accessibilité au réseau.

Par contre, j'ai un gros soucis de performance (pourtant l'Offloading est activé pour le forwarding / GRE / PPPoe / VLAN en IPv4 au niveau de l'ERLite).

Si je fais un gros IPerf3 vers ping.online.net en mode Routeur, je fais du 680 Mbit/s en Download, et dans les 250 Mbit/s en Upload.

Si je passe en mode bridge, et que je refais le test IPerf à partir du même serveur, je tourne systématiquement à 220 Mbit/s en Download et 250 Mbit/s en Upload.

Il y a un soucis niveau performance au niveau de l'ERLite, ou alors du mode bridge de la freebox mini 4K. Pourtant l'ERLite ne sature pas niveau charge CPU ... etrange !

A noter que la télévision fonctionne parfaitement en mode bridge, le boitier TV est synchro en Wifi 5Ghz sur mon Point d'accès wifi, 0 configuration de VLAN avec la Freebox mini 4K.

Je vais creuser le sujet pour la baisse de performance en mode bridge ... je ne sais pas trop pourquoi encore. Peut être justement parce que je ne précise aucun VLAN spécifique ... je ne sais pas.

Il faut que je teste avec un poste fixe avec interface reseau gigabit pour éliminer la piste du soucis au niveau de l'ERLite.

Il faudrait aussi que je teste en mode DHCP IPv6 pour le WAN... mais ça me semble pénible, et j'ai pas trop le temps pour le moment.

Wait&See

Didier




Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: Hugues le 10 juillet 2016 à 18:51:41
Tu as testé le test de débit local de la freebox ? Ça sera routé via l'ERL.

Et tu peux faire un Wget depuis la CLI de l'ERL aussi ;-)
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: AbP le 11 juillet 2016 à 11:28:56
Un test sous Windows qui fonctionne habituellement bien :
https://www.speedtest.net/fr/index.php

un autre :
https://testdebit.info/

Sans oublier les tests de neutralité présentés ici :
https://lafibre.info/tester-son-debit/test-neutralite/

ce qui donne par exemple sous Linux :
wget -O /dev/null ftp://3-ipv6.testdebit.info/1000Mo/1000Mo.iso

Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: Buzzer le 15 décembre 2016 à 15:44:05
Bonjour,

Seriez vous au courant de pb de performances sur l'infrastructure zmd de Free ? Car dans notre entreprise, nous utilisons Cisco anyconnect pour l'accès distant, qui permet en plus du https (tcp 443) de faire du dtls (udp 443). Le problème c'est que l'Infra zmd semble induire des perte de paquet, et la négociation du mtu dans le tunnel en dtls echoue 99% du temps. Mais pas en https car tcp gère les pertes de paquets.

Nous avons trouver 2 parades :
- bloquer le udp 443 pour les personnes ayant des soucis (autre que free)
- demander une ipv4 full stack (free uniquement)

Effectivement, passer en full stack supprime les pertes de paquets.
Pour l'instant le pb s'est présenté chez 10 freenautes et à été résolu avec une ip full stack. Vu le déploiement de Free je pense que le nombre de personnes concernées va augmenter.

Pour info, le dtls est deconfigurable, mais non souhaitable, car plus performant pour la TOIP. Le mtu dans le tunnel est paramétré à 1300 avec un overhead de 96 maxi. La négociation devrait donc passer des le premier paquet, mais à cause des pertes, ça echoue.

Donc 2 choses :
- Pb de perf sur l'Infra d'ip partagée ?
- différence d'Infra entre full stack et ip partagée ?

Merci des éventuelles infos.
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: alain_p le 15 décembre 2016 à 21:25:56
Bonjour Buzzer,

Merci pour la remontée des témoignages. Dans quelle région êtes-vous ? C'est peut-être un problème régional, ou même lié à un NRO/switch Free ?

Pour le MTU, Rani Assaf lui-même avait affirmé ici même qu'ils faisaient du jumbo frame, pour le tunnel IPv6 qui transporte l'IPv4, et donc que le MTU IPv4 était toujours de 1500 octets. Il y avait eu des problèmes au début des ZMDs et de la mise en place de cette techno 4rd, mais il avait été constaté ensuite que le MTU était bien en IPv4 de 1500. Il faudrait peut-être refaire des tests.

Pour l'IPv4 "full stack", ce serait une autre bonne raison de prendre l'option...

Sinon, ce qu'ont commencé à constater certains, c'est une baisse progressive des débits en ZMD, et cela peut venir effectivement de l'infrastructure. Si elle est surchargée, il peut y avoir des pertes de paquets.
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: Buzzer le 17 décembre 2016 à 09:54:42
Bonjour alain_p,

je pense que je me suis mal exprimé, je n'écris pas en tant que client FREE ayant des problèmes, mais en tant que service informatique d'une banque ayant des utilisateurs chez FREE, qui eux présentent un problème. La majorité des utilisateurs se situe en région parisienne en ZMD.
Ayant parcouru le thread, j'ai effectivement lu les informations selon lesquelles le MTU ne devrait pas être un problème. Cependant j'ai précisé notre configuration pour écarter ce sujet.
J'ai lu tous ce qu'il y avait a lire sur les technos mentionnées dans ce thread concernant la configuration FREE en ZMD.
Si je me suis décidé a écrire ici, c'est essentiellement parce qu'il est impossible de contacter FREE si on n'est pas client. J'ai essayé en vain.
Puisque certains ici semblent avoir des contacts autres, je me suis décidé à poster.

Je finirai par décrire rapidement la configuration utilisée :
anyconnect (le client vpn cisco) utilise 2 tunnels : un TCP-443 et un UDP-443.
le TCP est monté en premier, et lui fonctionne bien, puisque TCP gère les pertes de paquets.
l'UDP est ensuite établi (avec les infos du premier) et une tentative de détermination du MTU du tunnel est lancée, avec le principe du Keep-alive (envoi hello, réponse ok), de taille, qui décrèmente, jusqu'a obtenir une réponse.
Le problème est donc : dû aux pertes de paquets, les keep-alive de détermination de MTU, sont perdus. Le client considère que le MTU est trop bas, et il relance la négociation indéfiniment. le tunnel est donc inutilisable.

Vous me direz : désactive l'UDP, comme ça le tunnel TCP sera utilisé et tout ira bien. C'est vrai. mais ce n'est pas possible, puisque nos 2500 utilisateurs ne sont pas tous chez free en fibre en zmd, et que dans tous les autres cas le tunnel UDP fonctionne. Le tunnel UDP est nécessaire pour des questions de performance des applications de TOIP déployées sur les postes.

Bref, heureusement que le full stack ipv4 résoud le problème, sinon nous aurions été obligé de spécifier au support utilisateur de conseiller aux personnes impactées de changer d'opérateur.

Malgré la solution trouvée, je suis interressé pour comprendre ce qu'il se passe.
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: alain_p le 17 décembre 2016 à 10:12:17
Bonjour Buzzer,

Merci pour les précisions. En effet, il manquait certaines informations pour que je comprenne bien la situation. De ce que j'avais lu, vous n'étiez effectivement pas forcèment chez Free, mais vous auriez pu être une entreprise dont les employés se connectaient à distance à leur siège en employant ce moyen, et donc dans une région donnée.

Est-ce que vous auriez la possibilité d'utiliser l'IPv6 dans votre tunnel Cisco anyconnect ? C'est en effet l'IPv6 qui est utilisée par défaut en 4rd en ZMD. Je pensais aussi à la possibilité de faire un ping sur l'adresse de la box du client en IPv6, pour voir s'il y a des pertes de paquets, et éventuellement un traceroute en IPv6, pour voir à quel niveau se situerait le problème.
En ZMD, on ne peut pas pinger l'adresse IPv4 du client, évidemment quand elle est partagée, mais il me semble aussi quand elle est "full stack".

Est-ce que ce serait par exemple l'interconnexion qui pourrait poser problème ?
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: underground78 le 17 décembre 2016 à 10:23:57
Il est possible de pinger l'adresse IPv4 "full-stack".

PS : A mon avis il est possible d'avoir une réponse en contactant officiellement Free en tant que service technique de la banque dont les abonnés rencontrent des problèmes.
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: alain_p le 17 décembre 2016 à 10:57:52
Cela me rappelle qu'il y aussi la mailing list FRnOG sur laquelle certains officiels Free participent.

Merci sinon pour la précision, l'adresse "full stack" est donc pingable, mais ne pose pas de problème...
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: kgersen le 17 décembre 2016 à 11:29:26
oui FRnOG me semble la bonne piste et si on sort d'un forum grand public pour aller vers un truc pro/expert cela fera peut-être réagir Free...

c'est en plus la 'raison d’être' de FRnOG. C'est par la: http://www.frnog.org/?lang=fr (oui c'est un peu vieillot, a l'ancienne sous forme de mailing-list plutot qu'un site web 2.0 mais bon une fois de plus le dicton sur les cordonniers s’avère vrai ::)).
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: underground78 le 17 décembre 2016 à 11:30:35
Sinon il y a toujours l'option d'envoyer un MP à Rani Assaf sur le forum.
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: Buzzer le 17 décembre 2016 à 12:51:59
Bonjour,

merci pour vos infos.
Je me suis inscrit sur frong .... on verra bien ce quel se passe sur la mailing list.
Je n'ai pas la possibilité d'activé l'IPv6, car nous avons une infrastructure mutualisée avec le groupe et l'opérateur en place ne propose pas l'IPv6.
Le groupe n'a de toute façon pas de plan pour l'IPv6 ... ce que j'essaie de faire bouger.
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: alain_p le 17 décembre 2016 à 13:23:05
oui FRnOG me semble la bonne piste et si on sort d'un forum grand public pour aller vers un truc pro/expert cela fera peut-être réagir Free...

Ce forum est quand même pas mal consulté, et suivi. Si on commence à dire qu'il y a des problèmes avec l'IP partagée, et qu'il vaut prendre l'IP "Full stack", cela peut faire réagir. Car l'idée avec l'IP partagée, c'était quand même de faire des économies d'IPv4. Si tout le monde se met à prendre l'option, l'objectif sera un peu raté, et la publicité pas très bonne...

Il est clair que le nombre d'abonnés ZMD en 4rd augmente rapidement, et que les problèmes éventuels avec cette architecture vont être de plus en plus apparents.
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: juju299 le 25 mai 2018 à 20:20:06
Bonjour,
Je suis sur une infra DSLAM IPV6 FULL.
je suis arrivé avec LEDE/OpenWRT et un modem VDSL en Bridge à avoir l'IPV6 avec un tunnel 6to4 et j'ai mis mes IPV4 en dur.
Cependant je n'arrive toujours pas à avoir internet. Mais c'est quand même une avancée.
J'ai aussi cloné l'@ MAC.

La piste me semble intéressante.
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: Hugues le 25 mai 2018 à 21:51:10
Y'a rien de bon là.

L'IPv6 est une IPv6 6to4, donc pas bon.

Et l'IPv4 est portée via un tunnel 4Rd dans IPv6. Donc aucune chance de l'avoir comme ça.

Pour l'instant, personne n'a réussi a Bypass la Freebox en nouvelle archi.
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: Fuli10 le 25 mai 2018 à 21:54:42
Bonjour!
Enfin quelqu'un de volontaire pour faire la connection sur un DSLAMv6.
T'es en IP full stack? Si non, cela peut être la source du problème mais une commande iptables qui va bien devrait résoudre cela.
Quand tu tcpdump un ping depuis le LAN vers le net, tu vois bien le ping sortir encapsulé dans l'IPv6 avec la bonne IPv4 source (en gros le masquerading marche bien)?
Edit: j'avais pas vu le 6to4. Faudrait du 4to6 plutôt. C'est vraiment un DSLAMv6 ou c'est juste pour avoir l'IPv6 donné par le tunnel 6rd (un DSLAMv4)?
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: juju299 le 26 mai 2018 à 23:22:54
Bonjour,
C'est bien un DSLAM IPV6 et avec IPV6 activé.
Oui je suis en FullStack. Après en 6to4 LEDE trouve bien une IPV6 (DHCP) genre Tunnel avec une Gateway.
Autre observation, si je mets autre chose que mon IPV4 cela ne fonctionne pas.
Je vais faire de la copie de port et du wireshark pour voir ce qui passe entre le routeur et le modem en bridge.
Il se peut qu'il y ai quelque chose comme orange du genre un DHCP avec des paramètres ....

Pour Hugues, personne n'a réussi, mais y'a pas grand monde non plus qui poste des tentatives avec des config openwrt/LEDE, donc pas facile de réussir !

Ci dessous une capture WS.
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: Hugues le 26 mai 2018 à 23:29:17
Ouais non rien de choquant.

On voit bien le tunnel IPIP utilisé pour encapsuler v4 dans v6.

Du coup quel est le souci ? Suffit de trouver les IPs d'interco, mettre ton préfixe sur le LAN et ça passe, non ?

On peut même tenter un tunnel IPIP pour avoir de la v4 ;)




Par contre, DHCP en 6to4... T'as pas compris.

6To4, c'est un Tunnel, par dessus IPv4, qui utilise ton IPv4 publique pour mapper un préfixe IPv6, c'est pour ça que tu crois avoir une IP en 6to4. C'est de l'autoconf, pas du DHCP.

Pour moi, soit c'est du DHCPv6-PD sur un VLAN, soit c'est en statique avec conf TR-069 ou équivalent chez Free.

Du coup, suffit de sniffer, d'analyser les premières requètes, et ca devrait se clarifier :)
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: hwti le 27 mai 2018 à 00:01:35
Je me demande si en VDSL ils utilisent aussi les jumbo frames pour garder une MTU à 1500 sur l'IPv4.
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: Hugues le 27 mai 2018 à 00:24:18
Je pense oui, en vrai, c'est pas vraiment du Jumbo vu l'encapsulation...
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: Fuli10 le 27 mai 2018 à 07:01:32
Non en VDSL la MTU diffusées par le RA est de 1480. Donc pas de jumbo. D'ailleurs je ne sais pas si le chipset de la v5 supporte des frames > 1520 (L2 inclus).
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: Hugues le 27 mai 2018 à 10:41:56
Je vois pas le rapport, on parle de l’infra v6 only là, il n’y aura pas de MTU à 1480 pour v6 dans tous les cas puisqu’elle n’est pas encapsulée.

C’est assez rare les chips qui ne gèrent pas une MTU >1500, sans parler de Jumbo.
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: Fuli10 le 27 mai 2018 à 14:53:10
Bien vu... je suis fatigué pffff
Je ne sais pas si la MTU reste 1500 pour IPv4.
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: Hugues le 27 mai 2018 à 14:56:05
Yep, on verra :)

Moi je suis assez optimiste, les chips supportent bien jusqu'à 2000 octets sans souci.
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: juju299 le 27 mai 2018 à 15:04:49
Merci pour vos analyses.
Hugues, a mon avis c'est du DHCPV6-PD.
Du coup cela ressemblerais à la config OpenWRT ici : https://wiki.openwrt.org/doc/howto/freebox mais sans la free box.

ou peut-être un  "grev6tap" (Ethernet GRE tunnel over IPv6).

Par contre pour le IPV4 je vois pas.
Peut être des pistes ici :https://wiki.openwrt.org/doc/uci/network?s[]=tunnel&s[]=ipv6#protocol_gre_gre_tunnel_over_ipv4

Je fais un snif plus tard car pour l'instant j'ai mon gnome qui fait du FPS :-)
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: Hugues le 27 mai 2018 à 15:10:12
Hugues, a mon avis c'est du DHCPV6-PD.
Probable, pas certain sans capture :)

Du coup cela ressemblerais à la config OpenWRT ici : https://wiki.openwrt.org/doc/howto/freebox mais sans la free box.
Je ne vois pas le rapport, c'est de la délégation statique là. Du bête routage.

ou peut-être un  "grev6tap" (Ethernet GRE tunnel over IPv6).
Heu... Non. C'est du natif.

Par contre pour le IPV4 je vois pas.
C'est du 4Rd. A base d'IPIP et d'A+P d'après mes déductions.

Pas la peine de chercher de doc en fait, y'en a pas. Après je peux aider a en écrire et a décortiquer du pcap
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: kgersen le 27 mai 2018 à 15:59:50
le 4rd est pleinement documenté sous forme de RFC: https://tools.ietf.org/html/rfc7600.

c'est du tunneling sur mesh (donc 2 clients qui discutent en IPv4 le font par un tunnel direct au dessus de leur IPv6, ca ne passe par une gateway intermédiaire). La sortie IPv4 vers le reste du monde ce fait via des 'border relay 4rd' ou du NAT64+. cf la doc. Le tout est stateless.
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: Hugues le 27 mai 2018 à 16:13:01
Ce n'est pas ce qu'a dit Rani :

Oui, actuellement le trafic entre 2 abonnés "ipfixe ZMD" va passer par un noeud central (Courbevoie) mais on va rajouter par la
suite d'autre passerelle s'il y a vraiment assez de trafic pour le justifier

le 4rd est pleinement documenté sous forme de RFC: https://tools.ietf.org/html/rfc7600.
Je parlais plus de l'implèmentation chez Free.
Titre: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
Posté par: kgersen le 27 mai 2018 à 17:43:28
Je parlais plus de l'implèmentation chez Free.

c'est pas 100% la RFC? apres tout y'a qu'eux qui utilisent ca non ?  :P