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

0 Membres et 1 Invité sur ce sujet

tom pouce

  • Expert.
  • Abonné Sosh fibre
  • *
  • Messages: 2 612
  • Livebox Sosh - 77
FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
« Réponse #72 le: 28 février 2016 à 03:18:41 »
"elle" ?
Quelle hypothèse ? Commence par expliquer ça, ce sera plus simple de te suivre.

corrector

  • Invité
FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
« Réponse #73 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.

corrector

  • Invité
FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
« Réponse #74 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).

tom pouce

  • Expert.
  • Abonné Sosh fibre
  • *
  • Messages: 2 612
  • Livebox Sosh - 77
FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
« Réponse #75 le: 28 février 2016 à 03:52:29 »
Merci.

corrector

  • Invité
FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
« Réponse #76 le: 28 février 2016 à 04:08:54 »
Si on raisonne en terme d'entropie, je pense que c'est plus clair.

hwti

  • Abonné Orange Fibre
  • *
  • Messages: 2 237
  • Chambly (60)
FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
« Réponse #77 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.

corrector

  • Invité
FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
« Réponse #78 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.

alain_p

  • Abonné Free fibre
  • *
  • Messages: 16 245
  • Delta S 10G-EPON sur Les Ulis (91)
FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
« Réponse #79 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.

corrector

  • Invité
FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
« Réponse #80 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.

kgersen

  • Modérateur
  • Abonné Bbox fibre
  • *
  • Messages: 9 091
  • Paris (75)
FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
« Réponse #81 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.

vivien

  • Administrateur
  • *
  • Messages: 47 175
    • Twitter LaFibre.info
FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
« Réponse #82 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).