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

0 Membres et 1 Invité sur ce sujet

corrector

  • Invité
FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
« Réponse #60 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.
« Modifié: 27 février 2016 à 22:29:37 par corrector »

alain_p

  • Abonné Free fibre
  • *
  • Messages: 16 170
  • 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 #61 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.

corrector

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

alain_p

  • Abonné Free fibre
  • *
  • Messages: 16 170
  • 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 #63 le: 27 février 2016 à 22:45:09 »
Et encore ? Si tu prenais le temps de t'expliquer ?

kgersen

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

corrector

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

alain_p

  • Abonné Free fibre
  • *
  • Messages: 16 170
  • 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 #66 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.

kgersen

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



alain_p

  • Abonné Free fibre
  • *
  • Messages: 16 170
  • 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 #68 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.

alain_p

  • Abonné Free fibre
  • *
  • Messages: 16 170
  • 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 #69 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.

kgersen

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

corrector

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