Difference between revisions of "IPv6"
From Livre IPv6
(→Exemples) |
|||
| (15 intermediate revisions by 3 users not shown) | |||
| Line 2: | Line 2: | ||
Hormis la modification de la taille des adresses, ce qui conduit à une taille d'en-tête de 40 octets (le double de l'en-tête IPv4 sans les options), le protocole IP a subi un toilettage reprenant l'expérience acquise au fil des ans avec IPv4. Le format des en-têtes IPv6 est simplifié et permet aux routeurs de meilleures performances dans leurs traitements : | Hormis la modification de la taille des adresses, ce qui conduit à une taille d'en-tête de 40 octets (le double de l'en-tête IPv4 sans les options), le protocole IP a subi un toilettage reprenant l'expérience acquise au fil des ans avec IPv4. Le format des en-têtes IPv6 est simplifié et permet aux routeurs de meilleures performances dans leurs traitements : | ||
| − | + | ||
| − | * L'en-tête ne contient plus le champ checksum, qui devait être ajusté par chaque routeur en raison de la décrémentation du champ durée de vie. Par contre, pour éviter qu'un paquet dont le contenu est erroné -- en particulier sur l'adresse de destination -- ne se glisse dans une autre communication, tous les protocoles de niveau supérieur doivent mettre en | + | * L'en-tête ne contient plus le champ checksum, qui devait être ajusté par chaque routeur en raison de la décrémentation du champ durée de vie. Par contre, pour éviter qu'un paquet dont le contenu est erroné -- en particulier sur l'adresse de destination -- ne se glisse dans une autre communication, tous les protocoles de niveau supérieur doivent mettre en œuvre un mécanisme de checksum de bout en bout incluant un pseudo-en-tête qui prend en compte les adresses source et destination. Le checksum d'UDP, facultatif pour IPv4, devient ainsi obligatoire. Pour ICMPv6, le checksum intègre le pseudo-en-tête, alors que pour ICMPv4, il ne portait que sur le message ICMP. |
* La taille des en-têtes est fixe. Le routeur peut facilement déterminer où commence la zone de données utiles. | * La taille des en-têtes est fixe. Le routeur peut facilement déterminer où commence la zone de données utiles. | ||
* Les options ont été retirées de l'en-tête et remplacées par de nouveaux en-têtes appelés extensions qui peuvent être facilement ignorées par les routeurs intermédiaires. | * Les options ont été retirées de l'en-tête et remplacées par de nouveaux en-têtes appelés extensions qui peuvent être facilement ignorées par les routeurs intermédiaires. | ||
* Les champs sont alignés sur des mots de 64 bits, ce qui optimise leur traitement, surtout avec les nouvelles architectures à 64 bits. | * Les champs sont alignés sur des mots de 64 bits, ce qui optimise leur traitement, surtout avec les nouvelles architectures à 64 bits. | ||
| − | * La taille minimale des MTU : Maximum Transmission Unit est de 1 280 | + | * La taille minimale des MTU : Maximum Transmission Unit est de 1 280 octets. Le choix de 1 280 comme MTU minimal en IPv6 permet le tunnelage de paquets IPv6. En effet, la taille de 1 500 octets est généralement admise car elle correspond à la valeur imposée par Ethernet. La majorité des autres réseaux offrent une taille supérieure. La valeur de 576 octets retenue pour IPv4 permettait de prendre en compte des réseaux comme Appletalk. Pour ces réseaux, une couche d'adaptation (comme avec les couches d'adaptation AAL d'ATM) devra être mise en oeuvre pour pouvoir transporter les paquets IPv6. |
| − | * La fonction de fragmentation a été retirée des routeurs. Les champs qui s'y reportent (identification, drapeau, place du fragment) ont été supprimés. Normalement les algorithmes de découverte du PMTU Path MTU évitent d'avoir recours à la fragmentation. Si celle-ci s'avère nécessaire, une extension est prévue (voir | + | * La fonction de fragmentation a été retirée des routeurs. Les champs qui s'y reportent (identification, drapeau, place du fragment) ont été supprimés. Normalement les algorithmes de découverte du [[Mécanisme de découverte du PMTU|PMTU]](Path MTU) évitent d'avoir recours à la fragmentation. Si celle-ci s'avère nécessaire, une extension est prévue (voir [[Les_extensions#frag|Fragmentation]]). |
Le format d'en-tête d'un paquet IPv6 est donné par le RFC 2474 (cf. Format d'un datagramme IPv6). | Le format d'en-tête d'un paquet IPv6 est donné par le RFC 2474 (cf. Format d'un datagramme IPv6). | ||
| − | [[image: | + | [[image:Fig4-1.png|thumb|left|300px|Figure 4-1 ''Format d'un datagramme IPv6'']] |
; Version : Le champ version est le seul champ qui occupe la même place dans le paquet IPv6 et dans le paquet IPv4. Sa valeur est 6. | ; Version : Le champ version est le seul champ qui occupe la même place dans le paquet IPv6 et dans le paquet IPv4. Sa valeur est 6. | ||
| Line 20: | Line 20: | ||
; [[Identificateur de flux]] : | ; [[Identificateur de flux]] : | ||
| − | ; Longueur des données utiles (payload) :Contrairement à IPv4, ce champ, sur deux octets, ne contient que la taille des données utiles, sans prendre en compte la longueur de l'en-tête. Pour des paquets dont la taille des données serait supérieure à 65 535 ce champ vaut 0 et l'option jumbogramme de l'extension de "proche-en-proche" est utilisée (cf. | + | ; Longueur des données utiles (payload) :Contrairement à IPv4, ce champ, sur deux octets, ne contient que la taille des données utiles, sans prendre en compte la longueur de l'en-tête. Pour des paquets dont la taille des données serait supérieure à 65 535 ce champ vaut 0 et l'option jumbogramme de l'extension de "proche-en-proche" est utilisée (cf. [[Les_extensions#PeP|Jumbogramme]]) (type 194 ou 0xc2, RFC 2675 ). Cette option est utilisée quand le champ longueur des données du paquet IPv6 n'est pas suffisant pour coder la taille du paquet. Cette option est essentiellement prévue pour la transmission à grand débit entre deux équipements. Si l'option jumbogramme est utilisée, le champ longueur des données utiles dans l'en-tête IPv6 vaut 0. Noter que le type commence par la séquence binaire 11, ce qui permet au routeur ne traitant pas les jumbogrammes d'en informer la source. Celle-ci pourra réémettre l'information sans utiliser cette option.). |
| Line 29: | Line 29: | ||
Les extensions contiennent aussi ce champ pour permettre un chaînage. | Les extensions contiennent aussi ce champ pour permettre un chaînage. | ||
| − | ; Nombre de sauts : Il est décrémenté à chaque n?ud traversé. Un datagramme retransmis par un routeur est rejeté avec l'émission d'un message d'erreur ICMPv6 vers la source si la valeur après décrémentation atteint 0. <br> Dans IPv4 ce champ est appelé durée de vie (ou TTL Time To Live). Sa vocation initiale est d'indiquer, en secondes, la durée maximale durant laquelle un paquet peut rester dans le réseau. En pratique, les paquets ne restent que quelques millisecondes dans les routeurs, et donc la décrémentation est arrondie à 1. Par contre, pour une liaison plus lente la décrémentation de ce champ peut être supérieure à 1. Dans IPv6, comme il s'agit d'un nombre de sauts, la décrémentation est toujours de 1. <br>La valeur initiale de ce champ devrait être donnée dans un document annexe de l'IANA (http://www.iana.org/) | + | ; Nombre de sauts : Il est décrémenté à chaque n?ud traversé. Un datagramme retransmis par un routeur est rejeté avec l'émission d'un message d'erreur ICMPv6 vers la source si la valeur après décrémentation atteint 0. <br> Dans IPv4 ce champ est appelé durée de vie (ou TTL Time To Live). Sa vocation initiale est d'indiquer, en secondes, la durée maximale durant laquelle un paquet peut rester dans le réseau. En pratique, les paquets ne restent que quelques millisecondes dans les routeurs, et donc la décrémentation est arrondie à 1. Par contre, pour une liaison plus lente la décrémentation de ce champ peut être supérieure à 1. Dans IPv6, comme il s'agit d'un nombre de sauts, la décrémentation est toujours de 1. <br>La valeur initiale de ce champ devrait être donnée dans un document annexe de l'IANA (http://www.iana.org/) ce qui permettrait de la modifier en fonction de l'évolution de la topologie du réseau. La valeur n'est pas encore officiellement attribuée, mais certaines implantations prennent actuellement la valeur conseillée pour IPv4 : 64. <br>La valeur par défaut peut être dynamiquement attribuée aux équipements du réseau par les annonce des routeurs (cf. [[Configuration automatique]]), une modification de ce paramètre sera donc relativement simple quand la limite actuelle sera atteinte. On peut noter une limitation, puisque ce champ codé sur 8 bits n'autorise la traversée que de 255 routeurs. En réalité, dans l'Internet actuel, le nombre maximal de routeurs traversés est d'une quarantaine, ce qui laisse une bonne marge pour l'évolution du réseau. |
== Exemples == | == Exemples == | ||
| − | + | Le paquet IPv6 suivant a été capturé au cours d'une connexion FTP : | |
| − | 0000: 6<font color="blue">0 00</font> 00 00 00 28 06 40 3f fe 03 02 00 12 00 02 | + | ''0000: 6<font color="blue">0 0</font>0 00 00 <font color="blue">00 28</font> 06 <font color="blue">40</font> 3f fe 03 02 00 12 00 02'' |
| − | 0010: 00 00 00 00 00 00 00 13 3f fe 03 05 10 02 00 01 | + | ''0010: 00 00 00 00 00 00 00 13 <font color="blue">3f fe 03 05 10 02 00 01</font>'' |
| − | 0020: 02 00 c0 ff fe 11 cb a0|ff b3 00 15 55 4d fd d1 | + | ''0020: <font color="blue">02 00 c0 ff fe 11 cb a0</font>|ff b3 <font color="blue">00 15</font> 55 4d fd d1'' |
| − | 0030: 00 00 00 00 a0 02 40 00 7d 76 00 00 02 04 05 a0 | + | ''0030: <font color="blue">00 00 00 00</font> a0 <font color="blue">02</font> 40 00 <font color="blue">7d 76</font> 00 00 <font color="blue">02 04 05 a0</font>'' |
| − | 0040: 01 03 03 00 01 01 08 0a 00 9a 17 44 00 00 00 00 | + | ''0040: <font color="blue">01</font> 03 03 00 <font color="blue">01</font> 01 <font color="blue">08 0a 00 9a 17 44 00 00 00 00</font>'' |
| − | Le paquet commence par 6 qui indique la version du protocole. Le second champ 00 donne la classe de trafic DiffServ. L'identificateur de flux n'a pas été défini par la source (0 00 00). La longueur du paquet est de 0x0028 octets. Le paquet ne contient pas d'extension puisque la valeur de l'en-tête suivant, 0x06, correspond au protocole de niveau 4 TCP. Le nombre maximal de routeurs que le paquet pourra traverser est de 64 (0x40). Les adresses source et destination sont des adresses de test appartenant au plan d'adressage agrégé. | + | Le paquet commence par <tt>6</tt> qui indique la version du protocole. Le second champ <tt><font color="blue">00</font></tt> donne la classe de trafic ''DiffServ''. L'identificateur de flux n'a pas été défini par la source (<tt>0 00 00</tt>). La longueur du paquet est de <tt><font color="blue">0x0028</font></tt> octets. Le paquet ne contient pas d'extension puisque la valeur de l'en-tête suivant, <tt>0x06</tt>, correspond au protocole de niveau 4 TCP. Le nombre maximal de routeurs que le paquet pourra traverser est de 64 (<tt><font color="blue">0x40</font></tt>). Les adresses source et destination sont des adresses de test appartenant au plan d'adressage agrégé. |
{{suivi |Anycast|Anycast|Justification des extensions|Justification des extensions}} | {{suivi |Anycast|Anycast|Justification des extensions|Justification des extensions}} | ||
Latest revision as of 22:49, 20 February 2007
| |
Anycast | Table des matières | Justification des extensions | |
Hormis la modification de la taille des adresses, ce qui conduit à une taille d'en-tête de 40 octets (le double de l'en-tête IPv4 sans les options), le protocole IP a subi un toilettage reprenant l'expérience acquise au fil des ans avec IPv4. Le format des en-têtes IPv6 est simplifié et permet aux routeurs de meilleures performances dans leurs traitements :
- L'en-tête ne contient plus le champ checksum, qui devait être ajusté par chaque routeur en raison de la décrémentation du champ durée de vie. Par contre, pour éviter qu'un paquet dont le contenu est erroné -- en particulier sur l'adresse de destination -- ne se glisse dans une autre communication, tous les protocoles de niveau supérieur doivent mettre en œuvre un mécanisme de checksum de bout en bout incluant un pseudo-en-tête qui prend en compte les adresses source et destination. Le checksum d'UDP, facultatif pour IPv4, devient ainsi obligatoire. Pour ICMPv6, le checksum intègre le pseudo-en-tête, alors que pour ICMPv4, il ne portait que sur le message ICMP.
- La taille des en-têtes est fixe. Le routeur peut facilement déterminer où commence la zone de données utiles.
- Les options ont été retirées de l'en-tête et remplacées par de nouveaux en-têtes appelés extensions qui peuvent être facilement ignorées par les routeurs intermédiaires.
- Les champs sont alignés sur des mots de 64 bits, ce qui optimise leur traitement, surtout avec les nouvelles architectures à 64 bits.
- La taille minimale des MTU : Maximum Transmission Unit est de 1 280 octets. Le choix de 1 280 comme MTU minimal en IPv6 permet le tunnelage de paquets IPv6. En effet, la taille de 1 500 octets est généralement admise car elle correspond à la valeur imposée par Ethernet. La majorité des autres réseaux offrent une taille supérieure. La valeur de 576 octets retenue pour IPv4 permettait de prendre en compte des réseaux comme Appletalk. Pour ces réseaux, une couche d'adaptation (comme avec les couches d'adaptation AAL d'ATM) devra être mise en oeuvre pour pouvoir transporter les paquets IPv6.
- La fonction de fragmentation a été retirée des routeurs. Les champs qui s'y reportent (identification, drapeau, place du fragment) ont été supprimés. Normalement les algorithmes de découverte du PMTU(Path MTU) évitent d'avoir recours à la fragmentation. Si celle-ci s'avère nécessaire, une extension est prévue (voir Fragmentation).
Le format d'en-tête d'un paquet IPv6 est donné par le RFC 2474 (cf. Format d'un datagramme IPv6).
- Version
- Le champ version est le seul champ qui occupe la même place dans le paquet IPv6 et dans le paquet IPv4. Sa valeur est 6.
- Longueur des données utiles (payload)
- Contrairement à IPv4, ce champ, sur deux octets, ne contient que la taille des données utiles, sans prendre en compte la longueur de l'en-tête. Pour des paquets dont la taille des données serait supérieure à 65 535 ce champ vaut 0 et l'option jumbogramme de l'extension de "proche-en-proche" est utilisée (cf. Jumbogramme) (type 194 ou 0xc2, RFC 2675 ). Cette option est utilisée quand le champ longueur des données du paquet IPv6 n'est pas suffisant pour coder la taille du paquet. Cette option est essentiellement prévue pour la transmission à grand débit entre deux équipements. Si l'option jumbogramme est utilisée, le champ longueur des données utiles dans l'en-tête IPv6 vaut 0. Noter que le type commence par la séquence binaire 11, ce qui permet au routeur ne traitant pas les jumbogrammes d'en informer la source. Celle-ci pourra réémettre l'information sans utiliser cette option.).
- En-tête suivant
- Ce champ a une fonction similaire au champ protocole du paquet IPv4. Il identifie le prochain en-tête. Il peut s'agir d'un protocole (de niveau supérieur ICMP, UDP, TCP...) ou de la désignation d'extensions (cf. tableau Valeurs du champ en-tête suivant).
| valeur | Extension | valeur | Protocole | ||
|---|---|---|---|---|---|
| 0 | Proche-en-proche | 4 | IPv4 | ||
| 43 | Routage | 6 | TCP | ||
| 44 | Fragmentation | 17 | UDP | ||
| 50 | Confidentialité | 41 | IPv6 | ||
| 51 | Authentification | 58 | ICMPv6 | ||
| 59 | Fin des en-têtes | 132 | SCTP | ||
| 60 | Destination | 136 | UDP-lite | ||
| 135 | Mobilité | ||||
| 140 | Shim6 |
Les extensions contiennent aussi ce champ pour permettre un chaînage.
- Nombre de sauts
- Il est décrémenté à chaque n?ud traversé. Un datagramme retransmis par un routeur est rejeté avec l'émission d'un message d'erreur ICMPv6 vers la source si la valeur après décrémentation atteint 0.
Dans IPv4 ce champ est appelé durée de vie (ou TTL Time To Live). Sa vocation initiale est d'indiquer, en secondes, la durée maximale durant laquelle un paquet peut rester dans le réseau. En pratique, les paquets ne restent que quelques millisecondes dans les routeurs, et donc la décrémentation est arrondie à 1. Par contre, pour une liaison plus lente la décrémentation de ce champ peut être supérieure à 1. Dans IPv6, comme il s'agit d'un nombre de sauts, la décrémentation est toujours de 1.
La valeur initiale de ce champ devrait être donnée dans un document annexe de l'IANA (http://www.iana.org/) ce qui permettrait de la modifier en fonction de l'évolution de la topologie du réseau. La valeur n'est pas encore officiellement attribuée, mais certaines implantations prennent actuellement la valeur conseillée pour IPv4 : 64.
La valeur par défaut peut être dynamiquement attribuée aux équipements du réseau par les annonce des routeurs (cf. Configuration automatique), une modification de ce paramètre sera donc relativement simple quand la limite actuelle sera atteinte. On peut noter une limitation, puisque ce champ codé sur 8 bits n'autorise la traversée que de 255 routeurs. En réalité, dans l'Internet actuel, le nombre maximal de routeurs traversés est d'une quarantaine, ce qui laisse une bonne marge pour l'évolution du réseau.
Exemples
Le paquet IPv6 suivant a été capturé au cours d'une connexion FTP :
0000: 60 00 00 00 00 28 06 40 3f fe 03 02 00 12 00 02 0010: 00 00 00 00 00 00 00 13 3f fe 03 05 10 02 00 01 0020: 02 00 c0 ff fe 11 cb a0|ff b3 00 15 55 4d fd d1 0030: 00 00 00 00 a0 02 40 00 7d 76 00 00 02 04 05 a0 0040: 01 03 03 00 01 01 08 0a 00 9a 17 44 00 00 00 00
Le paquet commence par 6 qui indique la version du protocole. Le second champ 00 donne la classe de trafic DiffServ. L'identificateur de flux n'a pas été défini par la source (0 00 00). La longueur du paquet est de 0x0028 octets. Le paquet ne contient pas d'extension puisque la valeur de l'en-tête suivant, 0x06, correspond au protocole de niveau 4 TCP. Le nombre maximal de routeurs que le paquet pourra traverser est de 64 (0x40). Les adresses source et destination sont des adresses de test appartenant au plan d'adressage agrégé.
| |
Anycast | Table des matières | Justification des extensions | |
