Auteur Sujet: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau) (Lu 133941 fois)

« **Réponse #48 le:** 26 février 2016 à 22:32:40 »

Free/Orange :

hwti · « **Réponse #49 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 ?

vivien · « **Réponse #50 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.

Darklight · « **Réponse #51 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

« **Réponse #52 le:** 27 février 2016 à 17:09:31 »

Mode soi-disant bridge...

alain_p · « **Réponse #53 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.

kgersen · « **Réponse #54 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.

alain_p · « **Réponse #55 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.

« **Réponse #56 le:** 27 février 2016 à 21:01:29 »

Qui a dit qu'un paquet IPv4 était la charge utile d'un paquet IPv6?

alain_p · « **Réponse #57 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.

« **Réponse #58 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.

alain_p · « **Réponse #59 le:** 27 février 2016 à 21:25:47 »

Plus que moralement, si l'un des paquets est perdu, tu demandes de renvoyer quoi ?