Groupe de travail Réseau	R. Hinden, Nokia	
Request for Comments : 4291	S. Deering, Cisco Systems	
RFC rendue obsolète : 3513	février 2006	
Catégorie : En cours de normalisation	Traduction Claude Brière de L'Isle	

Architecture d'adressage d' IP version 6

Statut de ce mémoire
Le présent document spécifie un protocole Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et des suggestions pour son amélioration. Prière de se reporter à l’édition actuelle du STD 1 "Normes des protocoles officiels de l’Internet" pour connaître l’état de normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Notice de copyright
Copyright (C) The Internet Society (2006). Tous droits réservés

Résumé
La présente spécification définit l'architecture d'adressage du protocole IP version 6 (IPv6). Le document comporte le modèle d'adressage IPv6, les représentations textuelles des adresses IPv6, la définition des adresses IPv6 d'envoi individuel, des adresses d'envoi à la cantonade, et des adresses de diffusion groupée, ainsi que des adresses exigées d'un nœud IPv6.

Le présent document rend obsolète la RFC3513, "Architecture d'adressage de IP version 6".

Table des matières
1. Introduction	1
2. Adressage IPv6	2
2.1 Modèles d'adressage	2
2.2 Représentation textuelle des adresses	2
2.3 Représentation textuelle des préfixes d’adresse	3
2.4 Identification du type d’adresse	4
2.5 Adresses d’envoi individuel	4
2.5.1 Identifiants d’interface	5
2.5.2 L’adresse non spécifiée	5
2.5.3 L’adresse de bouclage	6
2.5.4 Adresses d’envoi individuel mondiales	6
2.5.5 Adresses IPv6 avec adresses IPv4 incorporées	6
2.5.6 Adresses IPv6 en envoi individuel de liaison locale	7
2.5.7 Adresses IPv6 en envoi individuel de site local	7
2.6 Adresses d’envoi à la cantonade	7
2.6.1 Adresse d’envoi à la cantonade exigée	8
2.7 Adresses de diffusion groupée	8
2.7.1 Adresses de diffusion groupée prédéfinies	10
2.8 Adresses exigées d’un nœud	11
3. Considérations pour la sécurité	11
4. Considérations relatives à l'IANA	11
5. Remerciements	11
6. Références	11
6.1. Références normatives	11
6.2. Références pour information	12
Appendice A Création d'identifiants d'interface de format EUI-64 modifié	12
Appendice B Changements par rapport à la RFC 3513	14
Déclaration complète de droits de reproduction	14

1.	Introduction

La présente spécification définit l’architecture d’adressage du protocole IP version 6 (IPv6). Elle inclut les formats de base pour les divers types d’adresses IPv6 (envoi individuel, envoi à la cantonade, et diffusion groupée).

2.	Adressage IPv6

Les adresses IPv6 sont des identifiants de 128 bits pour des interfaces et ensembles d’interfaces ("interface" est défini à la section 2 de [RFC2460]). Il y a trois types d’adresses :

Envoi individuel (unicast) : identifiant pour une seule interface. Un paquet envoyé à une adresse en envoi individuel est livré à l’interface identifiée par cette adresse.

Envoi à la cantonade (anycast) : identifiant pour un ensemble d’interfaces (appartenant normalement à des nœuds différents). Un paquet envoyé à une adresse d’envoi à la cantonade est livré à une des interfaces identifiées par cette adresse (la "plus proche", conformément aux mesures de distance des protocoles d’acheminement).

Envoi en diffusion  groupée (multicast) : identifiant pour un ensemble d’interfaces (appartenant normalement à des nœuds différents). Un paquet envoyé à une adresse de diffusion groupée est livré à toutes les interfaces identifiées par cette adresse.

Il n’y a pas d’adresses en diffusion dans IPv6, leur fonction étant absorbée par les adresses en diffusion groupée.

Dans le présent document, les champs dans les adresses ont reçu des noms spécifiques, par exemple "sous-réseau". Lorsque ce nom est utilisé avec le terme "ID" pour ‘identifiant’ avant le nom (par exemple, "ID de sous-réseau ") il se réfère au contenu du champ désigné. Lorsqu’il est utilisé avec le terme "préfixe" (par exemple, " préfixe de sous-réseau") il se réfère à toute l’adresse depuis la gauche jusque et y compris ce champ.

Dans IPv6, tous les zéros et tous les uns sont des valeurs légales pour tout champ, sauf mention contraire explicite. Précisément, les préfixes peuvent contenir, ou se terminer par des champs de valeur zéro.

2.1	Modèles d'adressage

Les adresses IPv6 de tous les types sont allouées aux interfaces, et non aux nœuds. Une adresse IPv6 en envoi individuel se réfère à une seule interface. Comme chaque interface appartient à un seul nœud, toute adresse en envoi individuel des interfaces de ce nœud peut être utilisée comme identifiant pour le nœud.

Toutes les interfaces sont obligées d’avoir au moins une adresse de liaison locale en envoi individuel (voir au paragraphe 2.8 les adresses supplémentaires exigées). Une seule interface peut aussi avoir plusieurs adresses IPv6 de tout type (envoi individuel, envoi à la cantonade, et diffusion groupée) ou toute portée. Les adresses en envoi individuel d’une portée supérieure à la portée de la liaison ne sont pas nécessaires pour les interfaces qui ne sont pas utilisés comme origine ou destination de paquets IPv6 de ou vers des non voisins. Cela est parfois pratique pour les interfaces point à point. Il y a une exception à ce modèle d’adressage : une adresse en envoi individuel ou un ensemble d’adresses en envoi individuel peut être alloué à plusieurs interfaces physiques si la mise en œuvre traite les différentes interfaces physiques comme une seule interface lorsqu’elle la présente à la couche Internet. C’est utile pour le partage de charge entre plusieurs interfaces physiques.

Actuellement, IPv6 continue le modèle IPv4 selon lequel un préfixe de sous-réseau est associé à une liaison. Plusieurs préfixes de sous-réseau peuvent être alloués à la même liaison.

2.2	Représentation textuelle des adresses

Il y a trois formes conventionnelles de représentation des adresses IPv6 comme chaînes textuelles :

1.	La forme préférée est x:x:x:x:x:x:x:x, où les 'x' sont de un à quatre chiffres hexadécimaux des huit morceaux de 16 bits de l’adresse.

Exemples :
ABCD:EF01:2345:6789:ABCD:EF01:2345:6789
2001:DB8:0:0:8:800:200C:417A

Noter qu’il n’est pas nécessaire d’écrire les séries de zéros en tête dans un champ individuel, mais il doit y avoir au moins un chiffre dans chaque champ (excepté pour le cas décrit en 2.).

2.	Du fait de certaines méthodes d’allocation de certains styles d’adresses IPv6, il sera courant que des adresses contiennent de longues chaînes de bits zéro. Afin de faciliter l’écriture des adresses contenant des bits zéro, une syntaxe spéciale est disponible pour compresser les zéros. L’utilisation de "::" indique un ou plusieurs groupes de 16 bits de zéros. Le "::" ne peut apparaître qu’une seule fois dans une adresse. Le "::" peut aussi être utilisé pour compresser les zéros de tête ou de queue dans une adresse.

Par exemple, dans les adresses suivantes :

1080:0:0:0:8:800:200C:417A	une adresse en envoi individuel
FF01:0:0:0:0:0:0:101	une adresse en diffusion groupée
0:0:0:0:0:0:0:1	l’adresse de bouclage
0:0:0:0:0:0:0:0	les adresses non spécifiées

peuvent être représentées comme :

1080::8:800:200C:417A	une adresse en envoi individuel
FF01::101	une adresse en diffusion groupée
::1	l’adresse de bouclage
::	l’adresse non spécifiée

3.	Une forme de remplacement qui est parfois plus pratique lorsqu’on a à faire à un environnement mêlé de nœuds IPv4 et IPv6 est x:x:x:x:x:x:d.d.d.d, où les 'x' sont les valeurs hexadécimales des six morceaux des 16 bits de poids fort de l’adresse, et les 'd' sont les valeurs décimales des quatre morceaux de 8 bits de moindre poids de l’adresse (représentation IPv4 standard).
Exemples :
0:0:0:0:0:0:13.1.68.3
0:0:0:0:0:FFFF:129.144.52.38

ou en forme compressée :
::13.1.68.3
::FFFF:129.144.52.38

2.3	Représentation textuelle des préfixes d’adresse

La représentation textuelle des préfixes d’adresses IPv6 est semblable à la façon dont sont écrits les préfixes des adresses IPv4 dans la notation d’acheminement inter domaine sans classe (CIDR, Classless Inter-Domain Routing) [RFC1519]. Un préfixe d’adresse IPv6 est représenté par la notation :

adresse-ipv6/longueur-de-préfixe

où :
adresse-ipv6 est une adresse IPv6 dans n’importe laquelle des notations dont la liste figure au paragraphe 2.2.
longueur-de-préfixe est une valeur décimale qui spécifie combien des bits contigus les plus à gauche de l’adresse comprend le préfixe.

Par exemple, ci-après sont des représentations légitimes du préfixe de 60 bits  20010DB80000CD3 (en hexadécimal) :

2001:0DB8:0000:CD30:0000:0000:0000:0000/60
2001:0DB8::CD30:0:0:0:0/60
2001:0DB8:0:CD30::/60

Ci-après sont des représentations NON légitimes du même préfixe :

2001:0DB8:0:CD3/60 	On peut laisser tomber les zéros en tête mais pas en queue, dans toute portion de 16 bits de l’adresse.

2001:0DB8::CD30/60 	L’adresse à gauche de  "/" se développe en 2001:0DB8:0000:0000:0000:0000:0000:CD30

2001:0DB8::CD3/60	L’adresse à gauche de "/" se développe en 2001:0DB8:0000:0000:0000:0000:0000:0CD3

Lorsqu’on écrit à la fois une adresse de nœud et un préfixe de cette adresse de nœud (par exemple, le préfixe de sous-réseau du nœud) les deux peuvent se combiner comme suit :

L’adresse du nœud 2001:0DB8:0:CD30:123:4567:89AB:CDEF et son numéro de sous-réseau 2001:0DB8:0:CD30::/60 peuvent être abrégés en 2001:0DB8:0:CD30:123:4567:89AB:CDEF/60

2.4	Identification du type d’adresse

Le type d’une adresse IPv6 est identifié par les bits de poids fort de l’adresse, comme suit :

Type d’adresse	Préfixe binaire	Notation IPv6	paragraphe	
Non spécifiée	00...0  (128 bits)	::/128	2.5.2	
Bouclage	00...1  (128 bits)	::1/128	2.5.3	
Diffusion groupée	11111111	FF00::/8	2.7	
Envoi individuel sur liaison locale 	1111111010	FE80::/10	2.5.6	
Envoi individuel mondial	(tout le reste)			

Les adresses en envoi à la cantonade sont tirées des espaces d’adresse d’envoi individuel (de toute portée) et ne peuvent être distinguées du point de vue de la syntaxe des adresses en envoi individuel.

Le format général des adresses d’envoi individuel mondiales est décrit au paragraphe 2.5.4. Certains sous-types spécialisés d’adresses d’envoi individuel mondiales qui contiennent des adresses IPv4 enchâssées (pour les besoins de l’interopérabilité IPv4-IPv6) sont décrits au paragraphe 2.5.5.

Des spécifications ultérieures pourront redéfinir une ou plusieurs sous-gammes de l’espace d’envoi individuel mondial pour d’autres objets, mais jusqu’à ce que cela arrive, les mises en œuvre doivent traiter toutes les adresses qui ne débutent pas par un des préfixes susmentionnés comme des adresses d’envoi individuel mondiales.

2.5	Adresses d’envoi individuel

Les adresses IPv6 en envoi individuel sont agrégeables à des préfixes de longueur binaire arbitraire semblables aux adresses IPv4 dans l’acheminement inter-domaine sans classe.

Il y a plusieurs types d’adresses en envoi individuel dans IPv6, en particulier l’envoi individuel mondial, l’envoi individuel de site local (déconseillé, voir au paragraphe 2.5.7) et l’envoi individuel de liaison locale. Il y a aussi des sous-types d’envoi individuel mondial à destination particulière, telles que les adresses IPv6 avec adresses IPv4 enchâssées. Des types ou sous-types d’adresses supplémentaires pourront être définis à l’avenir.

Les nœuds IPv6 peuvent en savoir beaucoup ou très peu sur la structure interne de l’adresse IPv6, selon le rôle joué par le nœud (par exemple, hôte contre routeur). Au minimum, un nœud peut considérer que les adresses en envoi individuel (y compris la sienne propre) n’ont pas de structure interne :

   |                           128 bits                              |
   +-----------------------------------------------------------------+
   |                          adresse de nœud                        |
   +-----------------------------------------------------------------+

Un hôte un peu sophistiqué (mais toujours assez simple) peut être en plus au courant du ou des préfixes de sous-réseau pour la ou les liaisons auxquelles il est rattaché, où différentes adresses peuvent avoir différentes valeurs pour n :

   |          n bits               |           128-n bits            |
   +-------------------------------+---------------------------------+
   |                   préfixe de sous-réseau       | ID d’interface |
   +-------------------------------+---------------------------------+

Bien qu’un routeur très simple puisse ne rien savoir de la structure interne des adresses IPv6 en envoi individuel, les routeurs auront normalement la connaissance d’une ou plusieurs frontières hiérarchiques pour le fonctionnement des protocoles d’acheminement. Les frontières connues vont différer d’un routeur à l’autre, en fonction de la position tenue par le routeur dans la hiérarchie d’acheminement.

Sauf pour la connaissance de la frontière de sous-réseau exposée aux paragraphes précédents, les nœuds ne devraient pas faire de suppositions sur la structure d’une adresse IPv6.

2.5.1	Identifiants d’interface
Dans les adresses IPv6 en envoi individuel, les identifiants d’interface sont utilisés pour identifier les interfaces sur une liaison. Il est nécessaire qu’ils soient uniques au sein d’un préfixe de sous réseau. Il est recommandé que le même identifiant d’interface ne soit pas alloué à différents noeuds sur une liaison. Ils peuvent aussi être uniques sur un domaine plus large. Dans certains cas, un identifiant d’interface va être déduit directement de l’adresse de couche liaison de cette interface. Le même identifiant d’interface peut être utilisé sur plusieurs interfaces d’un même noeud, pour autant qu’elles soient rattachées à des sous réseaux différents.

Noter que l’unicité des identifiants d’interface est indépendante de l’unicité des adresses IPv6. Par exemple, une adresse mondiale en envoi individuel peut être créée avec un identifiant d’interface d’une portée locale et une adresse de liaison locale peut être créée avec un identifiant d’interface de portée mondiale.
Pour toutes les adresses en envoi individuel, excepté celles qui commencent par la valeur binaire 000, les identifiants d’interface doivent être longs de 64 bits et être construits dans le format EUI-64 modifié.

Les identifiants d’interface fondés sur le format EUI-64 modifié peuvent avoir une portée mondiale lorsqu’ils sont déduits d’un jeton mondial (par exemple, des identifiants MAC IEEE 802 à 48 bits ou IEEE EUI-64 [EUI64]) ou peuvent avoir une portée locale lorsqu’un jeton mondial n’est pas disponible (par exemple, liaisons en série, points de terminaison de tunnels, etc.) ou lorsque des jetons mondiaux sont indésirables (par exemple, jetons temporaires pour la confidentialité [RFC3041]).

Les identifiants d’interface au format EUI-64 modifié sont formés en inversant le bit "u" (bit universel/local dans la terminologie EUI-64 de l’IEEE) lors de la formation de l’identifiant d’interface à partir des identifiants IEEE EUI-64. Dans le format EUI-64 modifié résultant, le bit "u" est mis à un (1) pour indiquer la portée mondiale, et il est mis à zéro (0) pour indiquer la portée locale. Les trois premiers octets en binaire d’un identifiant IEEE EUI-64 sont comme suit :

          0       0 0       1 1       2
         |0       7 8       5 6       3|
         +----+----+----+----+----+----+
         |cccc|ccug|cccc|cccc|cccc|cccc|
         +----+----+----+----+----+----+

écrit dans l’ordre binaire standard de l’Internet, où "u" est le bit universel/local, "g" est le bit individuel/groupe, et les "c" sont les bits de l’identifiant d’entreprise. L’Appendice A : "Création d’identifiants d’interface au format EUI-64 modifié" donne des exemples de création d’identifiants d’interface au format EUI-64 modifié.

La raison de l’inversion du bit "u" lors de la formation d’un identifiant d’interface est de faciliter la configuration manuelle par les administrateurs de système des identifiants non mondiaux lorsque des jetons de matériel ne sont pas disponibles. On s’attend à ce que ce soit le cas pour, par exemple, les liaisons en série, les points d’extrémité de tunnel. La solution de remplacement aurait été qu’ils soient de la forme 0200:0:0:1, 0200:0:0:2, etc., au lieu du beaucoup plus simple 0:0:0:1, 0:0:0:2, etc.

Les nœuds IPv6 ne sont pas obligés de valider que les identifiants d’interface créés avec des jetons EUI-64 modifié avec le bit "u" établi à universel sont uniques.

L’utilisation du bit universel/local dans l’identifiant au format EUI-64 modifié est destinée à permettre le développement de technologies qui à l’avenir puissent tirer parti des identifiants d’interface à portée mondiale.

Les détails de la formation des identifiants d’interface sont définis dans les spécifications "IPv6 sur <liaison>" appropriée, telles que "IPv6 sur Ethernet" [RFC2464], "IPv6 sur FDDI" [RFC2467], etc.

2.5.2	L’adresse non spécifiée
L’adresse 0:0:0:0:0:0:0:0 est appelée l’adresse non spécifiée. Elle ne doit jamais être allouée à aucun nœud. Elle indique l’absence d’adresse. Un exemple de son utilisation figure dans le champ Adresse de source de tout paquet IPv6 envoyé par un hôte qui initialise avant qu’il n’ait appris sa propre adresse.

L’adresse non spécifiée ne doit pas être utilisée comme adresse de destination de paquets IPv6 ou d’en-tête d’acheminement IPv6. Un paquet IPv6 avec une adresse de source non spécifiée ne doit jamais être transmis par un routeur IPv6.

2.5.3	L’adresse de bouclage
L’adresse en envoi individuel 0:0:0:0:0:0:0:1 est appelée l’adresse de bouclage. Elle peut être utilisée par un nœud pour s’envoyer un paquet IPv6 à lui-même. Elle ne doit jamais être allouée à une interface physique. Elle est traitée comme ayant une portée de liaison locale, et peut être considérée comme l’adresse en envoi individuel de liaison locale d’une interface virtuelle (appelée normalement "interface de bouclage") avec une liaison imaginaire qui ne mène nulle part.

L’adresse de bouclage ne doit pas être utilisée comme adresse de source dans les paquets IPv6 qui sont envoyés en-dehors d’un nœud unique. Un paquet IPv6 avec une adresse de destination de bouclage ne doit jamais être envoyé en-dehors d’un nœud unique et ne doit jamais être transmis par un routeur IPv6. Un paquet reçu sur une interface avec une adresse de destination de bouclage doit être abandonné.

2.5.4	Adresses d’envoi individuel mondiales
Le format général pour les adresses IPv6 en envoi individuel mondiales est le suivant :

   |         n bits         |   m bits  |       128-n-m bits         |
   +------------------------+-----------+----------------------------+
   | préfixe d’ache. mondial|ID de s/rés|  Identifiant d’interface   |
   +------------------------+-----------+----------------------------+

où le préfixe d’acheminement mondial est une valeur (normalement structurée hiérarchiquement) allouée à un site (une grappe de sous-réseaux/liaisons) l’ID de sous-réseau est un identifiant de liaison au sein du site, et l’ID d’interface est comme défini au paragraphe 2.5.1.

Toutes les adresses d’envoi individuel mondiales autres que celles qui commencent avec 000 binaire ont un champ d’identifiant d’interface de 64 bits (c’est-à-dire, n + m = 64) formaté comme décrit au paragraphe 2.5.1. Les adresses d’envoi individuel mondiales avec 000 binaire n’ont pas de telles contraintes sur la taille ou la structure du champ ID d’interface.

Des exemples d’adresse d’envoi individuel mondiale commençant avec 000 binaire sont l’adresse IPv6 avec des adresses IPv4 incorporées décrite au paragraphe 2.5.5. Un exemple d’adresse mondiale commençant par une valeur binaire autre que 000 (ayant donc un champ d’identifiant d’interface de 64 bits) se trouve dans la [RFC2374].

2.5.5	Adresses IPv6 avec adresses IPv4 incorporées
Deux types d’adresses IPv6 sont définis comme portant une adresse IPv4 dans les 32 bits de moindre poids de l’adresse. Ce sont "l’adresse IPv6 compatible IPv4" et "l’adresse IPv6 transposée en IPv4".

2.5.5.1	Adresse IPv6 compatible IPv4
L’adresse "IPv6 compatible IPv4" a été définie pour aider à la transition IPv6. Le format de l’adresse "IPv6 compatible IPv4" est le suivant :

   |                80 bits               | 16 |      32 bits        |
   +--------------------------------------+--------------------------+
   |0000..............................0000|0000|   adresse IPv4      |
   +--------------------------------------+----+---------------------+

Note : l’adresse IPv4 utilisée dans l’adresse "IPv6 compatible IPv4" doit être une adresse IPv4 en envoi individuel unique au niveau mondial.

L’adresse "IPv6 compatible IPv4" est maintenant déconseillée parce que le mécanisme actuel de transition IPv6 n’utilise plus ces adresses. Les mises en œuvre nouvelles ou mises à jour ne sont plus obligées de prendre en charge ce type d’adresse.

2.5.5.2	Adresse IPv6 transposée en IPv4
Un second type d’adresse IPv6 contenant une adresse IPv4 incorporée est défini. Ce type d’adresse est utilisé pour représenter les adresses de nœuds IPv4 comme des adresses IPv6. Le format de l’adresse "IPv6 transposée en IPv4" est le suivant :

   |                80 bits               | 16 |      32 bits        |
   +--------------------------------------+--------------------------+
   |0000..............................0000|FFFF|    adresse IPv4     |
   +--------------------------------------+----+---------------------+

Voir dans la [RFC4038] les fondements de l’usage de l’adresse "IPv6 transposée en IPv4".

2.5.6	Adresses IPv6 en envoi individuel de liaison locale
Les adresses  de liaison locale sont à utiliser sur une seule liaison. Les adresses de liaison locale ont le format suivant :

   |   10     |
   |  bits    |         54 bits         |          64 bits           |
   +----------+-------------------------+----------------------------+
   |1111111010|           0             |  Identifiant d’interface   |
   +----------+-------------------------+----------------------------+

Les adresses de liaison locale sont conçues pour être utilisées dans l’adressage sur une seule liaison pour des besoins tels que la configuration automatique d’adresse, la découverte de voisins, ou lorsque aucun routeur n’est présent.

Les routeurs ne doivent transmettre aucun paquet avec des adresses de liaison locale de source ou de destination à d’autres liaisons.

2.5.7	Adresses IPv6 en envoi individuel de site local
Les adresses de site local étaient à l’origine conçues pour être utilisées pour l’adressage à l’intérieur d’un site sans avoir besoin d’un préfixe mondial. Les adresses de site local sont maintenant déconseillées, comme défini dans la [RFC3879].

Les adresses de site local ont le format suivant :

   |   10     |
   |  bits    |         54 bits         |         64 bits            |
   +----------+-------------------------+----------------------------+
   |1111111011|    ID de sous-réseau    |  Identifiant d’interface   |
   +----------+-------------------------+----------------------------+

Le comportement particulier de ce préfixe défini dans la [RFC3513] ne doit plus être pris en charge dans les nouvelles mises en œuvre (c’est-à-dire que les nouvelles mises en œuvre doivent traiter ce préfixe comme de l’envoi individuel mondial).

Les mises en œuvre et développements existants peuvent continuer d’utiliser ce préfixe.

2.6	Adresses d’envoi à la cantonade

Une adresse IPv6 d’envoi à la cantonade est une adresse qui est allouée à plus d’une interface (appartenant normalement à des nœuds différents) avec la propriété qu’un paquet envoyé à une adresse d’envoi à la cantonade est acheminé à l’interface "la plus proche" qui a cette adresse, conformément à la mesure des distances du protocole d’acheminement.

Les adresses d’envoi à la cantonade sont allouées à partir de l’espace d’adresse d’envoi individuel, en utilisant tout format d’adresse d’envoi individuel défini. Et donc, les adresses d’envoi à la cantonade sont syntaxiquement indistinguables des adresses d’envoi individuel. Lorsqu’une adresse d’envoi individuel est allouée à plus d’une interface, ce qui la transforme donc en adresse d’envoi à la cantonade, les nœuds auxquels l’adresse est allouée doivent être explicitement configurés pour comprendre qu’il s’agit d’une adresse d’envoi à la cantonade.

Pour toute adresse d’envoi à la cantonade allouée, il y a un plus long préfixe P de cette adresse qui identifie la région topologique dans laquelle résident toutes les interfaces appartenant à cette adresse d’envoi à la cantonade. Au sein de la région identifiée par P, l’adresse d’envoi à la cantonade doit être maintenue comme une entrée séparée dans le système d’acheminement (désigné habituellement comme un "acheminement d’hôte") ; en-dehors de la région identifiée par P, l’adresse d’envoi à la cantonade peut être agrégée dans l’entrée d’acheminement pour le préfixe P.

Noter que dans le plus mauvais cas, le préfixe P d’un ensemble d’envoi à la cantonade peut être le préfixe nul, c’est-à-dire que les membres de l’ensemble peuvent n’avoir aucune localisation topologique. Dans ce cas, l’adresse d’envoi à la cantonade doit être maintenue comme entrée d’acheminement distincte dans l’Internet tout entier, ce qui représente une limite d’échelle sévère au nombre d’ensembles d’envoi à la cantonade "mondiaux" qui peuvent être pris en charge. On s’attend donc à ce que la prise en charge d’ensembles d’envoi à la cantonade mondiaux soit presque indisponible ou très restreinte.

Une utilisation attendue des adresses d’envoi à la cantonade est d’identifier l’ensemble des routeurs qui appartiennent à une organisation qui fournit des services Internet. De telles adresses pourraient être utilisées comme adresses intermédiaires dans un en-tête d’acheminement IPv6, pour provoquer la livraison d’un paquet via un fournisseur de service particulier ou une séquence de fournisseurs de service.

D’autres utilisations possibles sont l’identification de l’ensemble des routeurs attachés à un sous-réseau particulier, ou l’ensemble des routeurs qui fournissent l’entrée dans un domaine d’acheminement particulier.

2.6.1	Adresse d’envoi à la cantonade exigée
L’adresse d’envoi à la cantonade Routeur-de-sous-réseau est prédéfinie. Son format est comme suit :

   |                         n bits                 |   128-n bits   |
   +------------------------------------------------+----------------+
   |             préfixe de sous-réseau             | 00000000000000 |
   +------------------------------------------------+----------------+

Le "préfixe de sous-réseau" dans une adresse d’envoi à la cantonade est le préfixe qui identifie une liaison spécifique. Cette adresse d’envoi à la cantonade est syntaxiquement la même qu’une adresse d’envoi individuel pour une interface sur la liaison avec l’identifiant d’interface mis à zéro.

Les paquets envoyés à l’adresse d’envoi à la cantonade Routeur-de-sous-réseau seront livrés à un routeur sur le sous réseau. Tous les routeurs sont tenus de prendre en charge les adresses d’envoi à la cantonade Routeur-de-sous-réseau pour les sous réseaux avec lesquels ils ont des interfaces.

L’adresse d’envoi à la cantonade Routeur-de-sous-réseau est destinée à être utilisée par des applications où un nœud a besoin de communiquer avec un routeur quelconque de l’ensemble des routeurs.

2.7	Adresses de diffusion groupée

Une adresse IPv6 de diffusion groupée est un identifiant pour un groupe d’interfaces (normalement sur des nœuds différents). Une interface peut appartenir à tout nombre de groupes de diffusion groupée. Les adresses de diffusion groupée ont le format suivant :

   |   8    |  4 |  4 |                  112 bits                   |
   +------ -+----+----+---------------------------------------------+
   |11111111|fan.|port|            Identifiant de groupe            |
   +--------+----+----+---------------------------------------------+

11111111 en binaire au début de l’adresse identifie l’adresse comme étant une adresse de diffusion groupée. 

                                         +-+-+-+-+
fan. est un ensemble de quatre fanions : |0|0|0|T|
                                         +-+-+-+-+

Les trois fanions de poids fort sont réservés, et doivent être initialisés à 0.

T = 0	indique une allocation permanente ("bien connue") d’adresses de diffusion groupée, allouées par l’autorité d’allocation des numéros de l’Internet (IANA, Internet Assigned Number Authority).

T = 1 	indique une adresse de diffusion groupée allouée de façon non permanente (allouée de façon "transitoire" ou "dynamique").

La définition et l’usage du fanion P se trouvent dans la [RFC3306].

La définition et l’usage du fanion R se trouvent dans la [RFC3956].

port est une valeur de portée de diffusion groupée de 4 bits utilisée pour limiter la portée du groupe de diffusion groupée. Les valeurs sont :
0	réservé
1	portée d’interface locale
2	portée de liaison locale
3	réservé
4	portée d’administration locale
5	portée de site local
6	(non allouée)
7	(non allouée)
8	portée d’organisation locale
9	(non allouée)
A	(non allouée)
B	(non allouée)
C	(non allouée)
D	(non allouée)
E	portée mondiale
F	réservé

La portée d’interface locale ne couvre qu’une seule interface sur un nœud, et ne sert que pour la transmission en bouclage en diffusion groupée.

Une portée de liaison locale en diffusion groupée couvre la même région topologique que la portée d’envoi individuel correspondante.

La portée d’administration locale est la plus petite portée qui doit être configurée administrativement, c’est-à-dire, non automatiquement déduite de la connexité physique, ou autre configuration ne relevant pas de la diffusion groupée.

La portée site local est destinée à s’étendre sur un seul site.

La portée d’organisation locale est destinée à couvrir plusieurs sites appartenant à une seule organisation.

Les portées marquées "(non allouée)" sont disponibles pour que les administrateurs définissent des régions de diffusion groupée supplémentaires.

Identifiant de groupe identifie le groupe de diffusion groupée, permanent ou transitoire, au sein de la portée donnée. Des définitions supplémentaires de la structure du champ Identifiant de groupe de diffusion groupée figurent dans la [RFC3306].

La "signification" d’une adresse de diffusion groupée allouée de façon permanente est indépendante de la valeur de la portée. Par exemple, si "groupe de serveurs NTP" reçoit une adresse de diffusion groupée permanente avec un identifiant de groupe de 101 (hex), alors :
FF01:0:0:0:0:0:0:101 signifie tous les serveurs NTP sur la même interface (c’est-à-dire le même nœud) que l’envoyeur,
FF02:0:0:0:0:0:0:101 signifie tous les serveurs NTP sur la même liaison que l’envoyeur,
FF05:0:0:0:0:0:0:101 signifie tous les serveurs NTP sur le même site que l’envoyeur,
FF0E:0:0:0:0:0:0:101 signifie tous les serveurs NTP dans l’Internet.

Les adresses de diffusion groupée allouées de façon non permanente ne sont significatives qu’à l’intérieur d’un domaine d’application donné. Par exemple, un groupe identifié par l’adresse de diffusion groupée de site local non permanente FF15:0:0:0:0:0:0:101 à un site, n’emporte aucune relation avec un groupe utilisant la même adresse sur un site différent, pas plus qu’avec un groupe non permanent utilisant le même identifiant de groupe avec un domaine d’application différent, ni avec un groupe permanent avec le même ID de groupe.

Les adresses de diffusion groupée ne doivent pas être utilisées comme adresses de source dans les paquets IPv6, ni apparaître dans un en-tête d’acheminement.

Les routeurs ne doivent pas transmettre de paquets en diffusion groupée au-delà de la portée indiquée par le champ Portée dans l’adresse de diffusion groupée de destination.

Les nœuds ne doivent pas générer un paquet vers une adresse de diffusion groupée dont le champ Portée contient la valeur réservée 0 ; si un tel paquet est reçu, il doit être supprimé en silence. Les nœuds ne devraient pas générer de paquet vers une adresse de diffusion groupée dont le champ Portée contient la valeur réservée F ; si un tel paquet est envoyé ou reçu, il doit être traité comme les paquets destinés à une adresse de diffusion groupée mondiale (portée E).

2.7.1	Adresses de diffusion groupée prédéfinies
Les adresses de diffusion groupée bien connues suivantes sont prédéfinies. Les identifiants de groupe de ce paragraphe sont définis pour des valeurs de portée explicites.

L’utilisation de ces identifiants de groupe pour toute autre valeur de portée, avec le fanion T égal à 0, est interdite.

Adresses de diffusion groupée réservées :	FF00:0:0:0:0:0:0:0
	FF01:0:0:0:0:0:0:0
	FF02:0:0:0:0:0:0:0
	FF03:0:0:0:0:0:0:0
	FF04:0:0:0:0:0:0:0
	FF05:0:0:0:0:0:0:0
	FF06:0:0:0:0:0:0:0
	FF07:0:0:0:0:0:0:0
	FF08:0:0:0:0:0:0:0
	FF09:0:0:0:0:0:0:0
	FF0A:0:0:0:0:0:0:0
	FF0B:0:0:0:0:0:0:0
	FF0C:0:0:0:0:0:0:0
	FF0D:0:0:0:0:0:0:0
	FF0E:0:0:0:0:0:0:0
	FF0F:0:0:0:0:0:0:0

Les adresses de diffusion groupée ci-dessus sont réservées et ne doivent jamais être allouées à un groupe de diffusion groupée.

Adresses Tous-les-nœuds :	FF01:0:0:0:0:0:0:1
	FF02:0:0:0:0:0:0:1

Les adresses de diffusion groupée ci-dessus identifient le groupe de tous les nœuds IPv6, dans le domaine d’application 1 (interface locale) ou 2 (liaison locale).

Adresses Tous-les-routeurs :	FF01:0:0:0:0:0:0:2
	FF02:0:0:0:0:0:0:2
	FF05:0:0:0:0:0:0:2

Les adresses de diffusion groupée ci-dessus identifient le groupe de tous les routeurs IPv6, dans le domaine d’application 1 (interface locale), 2 (liaison locale), ou 5 (site local).

Adresse de nœud sollicité :	FF02:0:0:0:0:1:FFXX:XXXX

Une adresse de diffusion groupée de nœud sollicité est calculée comme une fonction des adresses d’envoi individuel et d’envoi à la cantonade d’un nœud. Une adresse de diffusion groupée de nœud sollicité est formée en prenant les 24 bits de moindre poids d’une adresse (en envoi individuel ou en envoi à la cantonade) et en ajoutant ces bits au préfixe FF02:0:0:0:0:1:FF00::/104 ce qui donne une adresse de diffusion groupée dans la gamme FF02:0:0:0:0:1:FF00:0000 à FF02:0:0:0:0:1:FFFF:FFFF.

Par exemple, l’adresse de diffusion groupée de nœud sollicité correspondant à l’adresse IPv6 4037::01:800:200E:8C6C est FF02::1:FF0E:8C6C. Les adresses IPv6 qui diffèrent seulement par les bits de plus fort poids, c’est-à-dire, du fait de plusieurs préfixes de rang élevé associés aux différentes agrégations, vont se transposer dans la même adresse de diffusion groupée de nœud sollicité, réduisant par là le nombre d’adresses de diffusion groupée qu’un nœud doit joindre.

Il est exigé d’un nœud qu’il calcule et joigne (sur l’interface appropriée) les adresses de diffusion groupée de nœud sollicité associées pour toutes les adresses d’envoi individuel et d’envoi à la cantonade qui ont été configurées pour les interfaces du nœud (manuellement ou automatiquement).

2.8	Adresses exigées d’un nœud

Il est exigé d’un hôte qu’il reconnaisse les adresses suivantes lorsqu’il s’identifie lui-même :
•	Son adresse de liaison locale exigée pour chaque interface.
•	Toutes adresses d’envoi individuel ou d’envoi à la cantonade supplémentaire qui ont été configurées pour les interfaces du nœud (manuellement ou automatiquement).
•	L’adresse de bouclage.
•	Les adresses de diffusion groupée Tous-les-nœuds définies au paragraphe 2.7.1.
•	L’adresse de diffusion groupée de nœud sollicité pour chacune de ses adresses d’envoi individuel et d’envoi à la cantonade.
•	Les adresses de diffusion groupée de tous les autres groupes auxquels le nœud appartient.

Il est exigé d’un routeur qu’il reconnaisse toutes les adresses qu’un hôte doit reconnaître, plus les adresses suivantes, lorsqu’il s’identifie lui-même :
•	Les adresses d’envoi à la cantonade de routeur de sous-réseau pour toutes les interfaces pour lesquelles il est configuré pour agir comme routeur.
•	Toutes les autres adresses d’envoi à la cantonade avec lesquelles le routeur a été configuré.
•	Les adresses de diffusion groupée Tous-les-routeurs définies au paragraphe 2.7.1.

3.	Considérations pour la sécurité

Les documents sur l’adressage IPv6 n’ont pas d’impact direct sur la sécurité de l’infrastructure de l’Internet. L’authentification des paquets IPv6 est définie dans [RFC2402].

4.	Considérations relatives à l'IANA

L’adresse "IPv6 compatible IPv4" est déconseillée par le présent document. L’IANA devrait continuer de faire la liste des blocs d’adresse contenant ces adresses à http://www.iana.org/assignments/ipv6-address-space comme "Réservé par l’IETF" et ne pas les réallouer pour d’autres objets. Par exemple :

0000::/8	Réservé par l’IETF	[RFC3513]	[1]

L’IANA a ajouté la note et le lien suivants à ce bloc d’adresse.

[5]	0000::/96 était précédemment défini comme préfixe d’adresse "IPv6 compatible IPv4". Cette définition a été déconseillée par la RFC 4291.

L’IANA a mis à jour en conséquence les références à l’architecture d’adresse IPv6 dans les registres de l’IANA.

5.	Remerciements

Les auteurs tiennent à remercier de leurs contributions Paul Francis, Scott Bradner, Jim Bound, Brian Carpenter, Matt Crawford, Deborah Estrin, Roger Fajman, Bob Fink, Peter Ford, Bob Gilligan, Dimitry Haskin, Tom Harsch, Christian Huitema, Tony Li, Greg Minshall, Thomas Narten, Erik Nordmark, Yakov Rekhter, Bill Simpson, Sue Thomson, Markku Savela, Larry Masinter, Jun-ichiro Itojun Hagino, Tatuya Jinmei, Suresh Krishnan, et Mahmood Ali.

6.	Références
6.1.	Références normatives
[RFC2460]	S. Deering et R. Hinden, "Spécification du protocole Internet, version 6 (IPv6) ", décembre 1998. (MàJ par RFC5095 , D.S)

6.2.	Références pour information
[EUI64]	IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) Registration Authority", http://standards.ieee.org/regauth/oui/tutorials/EUI64.html, mars 1997.

[RFC1519]	V. Fuller, T. Li, J. Yu et K. Varadhan, "Acheminement inter domaine sans classe (CIDR) : stratégie d'allocation et d'agrégation d'adresses", septembre 1993. (D.S., rendue obsolète par la RFC4632 )

[RFC2402]	S. Kent et R. Atkinson, "En-tête d'authentification IP", novembre 1998. (Obsolète, voir RFC4302, 4305)

[RFC2464]	M. Crawford, "Transmission de paquets IPv6 sur réseaux Ethernet", décembre 1998. (P.S.)

[RFC2467]	M. Crawford, "Transmission de paquets IPv6 sur réseaux FDDI", décembre 1998. (P.S.)

[RFC3041]	T. Narten, R. Draves, "Extensions de confidentialité pour l'auto-configuration d'adresse sans état dans IPv6", janvier 2001. (Obsolète, voir RFC4941) (P.S.)

[RFC3306]	B. Haberman, D. Thaler, "Adresses de diffusion groupé IPv6 fondées sur des préfixes d'envoi individuel", août 2002. (MàJ par RFC3956, RFC4489) (P.S.)

[RFC3513]	R. Hinden et S. Deering, "Architecture d'adressage du protocole Internet version 6 (IPv6)", avril 2003. (Obs. voir RFC4291)

[RFC3587]	R. Hinden, S. Deering, E. Nordmark, "Format mondial d'adresse IPv6 en envoi individuel", août 2003. (Information)

[RFC3879]	C. Huitema, B. Carpenter, "Les adresses IPv6 de site local en envoi individuel sont déconseillées", septembre 2004. (P.S.)

[RFC3956]	P. Savola, B. Haberman, "Incorporation de l'adresse de point de rendez-vous (RP) dans une adresse de diffusion groupée IPv6", novembre 2004. (P.S.)

[RFC4038]	M-K. Shin et autres, "Aspects de l'application de la transition vers IPv6", mars 2005. (Information)

Appendice A	Création d'identifiants d'interface de format EUI-64 modifié

Selon les caractéristiques d’une liaison ou nœud spécifique, il existe un certain nombre d’approches pour la création d’identifiants d’interface au format EUI-64 modifié. Le présent appendice décrit quelques unes de ces approches.

Liaisons ou nœuds avec identifiants IEEE EUI-64
Le seul changement nécessaire pour transformer un identifiant IEEE EUI-64 en identifiant d’interface est d’inverser le bit "u" (universel/local). Par exemple, un identifiant IEEE EUI-64 mondialement unique de la forme :

   |0              1|1              3|3              4|4              6|
   |0              5|6              1|2              7|8              3|
   +----------------+----------------+----------------+----------------+
   |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm|
   +----------------+----------------+----------------+----------------+

où "c" sont les bits de l’identifiant d’entreprise alloué, "0" est la valeur du bit universel/local pour indiquer la portée mondiale, "g" est le bit individuel/groupe, et "m" sont les bits de l’identifiant d’extension choisi par le fabricant. L’identifiant d’interface serait de la forme : 

   |0              1|1              3|3              4|4              6|
   |0              5|6              1|2              7|8              3|
   +----------------+----------------+----------------+----------------+
   |cccccc1gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm|
   +----------------+----------------+----------------+----------------+

Le seul changement est l’inversion de la valeur du bit universel/local.

Liaisons ou nœuds avec des MAC IEEE 802 à 48 bits
[EUI64] définit une méthode de création d’identifiant IEEE EUI-64 à partir d’un identifiant MAC IEEE à 48 bits. C’est d’insérer deux octets, avec des valeurs hexadécimales de 0xFF et 0xFE (voir la Note à la fin de l’appendice), au milieu du MAC de 48 bits (entre l’identifiant d’entreprise et l’identifiant fourni par le fabricant). Par exemple, le MAC IEEE de 48 bits à portée mondiale :

   |0              1|1              3|3              4|
   |0              5|6              1|2              7|
   +----------------+----------------+----------------+
   |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|
   +----------------+----------------+----------------+

où les "c" sont les bits de l’identifiant d’entreprise alloué, "0" est la valeur du bit universel/local pour indiquer la portée mondiale, "g" est le bit individuel/groupe, et les "m" sont les bits de l’identifiant d’extension choisi par le fabricant. L’identifiant d’interface serait de la forme :

   |0              1|1              3|3              4|4              6|
   |0              5|6              1|2              7|8              3|
   +----------------+----------------+----------------+----------------+
   |cccccc1gcccccccc|cccccccc11111111|11111110mmmmmmmm|mmmmmmmmmmmmmmmm|
   +----------------+----------------+----------------+----------------+

Lorsque des adresses MAC IEEE 802 à 48 bits sont disponibles (sur une interface ou un nœud), une mise en œuvre peut les utiliser pour créer des identifiants d’interface à cause de leurs propriétés de disponibilité et d’unicité.

Liaisons avec d’autres sortes d’identifiants
Il y a de nombreux types de liaisons qui ont des identifiants d’interface de couche liaison autres que les MAC IEEE EIU-64 ou IEEE 802 à 48 bits. Les exemples incluent LocalTalk et Arcnet. La méthode de création d’un identifiant de format EUI-64 modifié est de prendre l’identifiant de liaison (par exemple, l’identifiant de noeud LocalTalk à 8 bits) et de le remplir de zéros sur la gauche. Par exemple, un identifiant de nœud LocalTalk à 8 bits de valeur hexadécimale 0x4F donnera l’identifiant d’interface suivant :

   |0              1|1              3|3              4|4              6|
   |0              5|6              1|2              7|8              3|
   +----------------+----------------+----------------+----------------+
   |0000000000000000|0000000000000000|0000000000000000|0000000001001111|
   +----------------+----------------+----------------+----------------+

Noter qu’il en résulte que le bit universel/local est mis à "0" pour indiquer la portée locale.

Liaisons sans identifiant
Un certain nombre de liaisons n’ont aucun type d’identifiant préconstruit. Les plus courantes d’entre elles sont les liaisons en série et les tunnels configurés. Les identifiants d’interface doivent être choisis comme étant uniques au sein d’un préfixe de sous-réseau.

Lorsque aucun identifiant préconstruit n’est disponible sur une liaison, l’approche préférée est d’utiliser un identifiant d’interface mondial d’une autre interface ou un identifiant qui est alloué au nœud lui-même. Lorsqu’on utilise cette approche, aucune autre interface connectant le même nœud au même préfixe de sous-réseau ne peut utiliser le même identifiant.

Si aucun identifiant mondial d’interface n’est disponible pour être utilisé sur la liaison, la mise en œuvre va devoir créer un identifiant d’interface de portée locale. La seule exigence est qu’il soit unique au sein du préfixe de sous-réseau. De nombreuses approches sont possibles pour choisir un identifiant d’interface unique dans un préfixe de sous-réseau. Cela inclut :
la configuration manuelle
le numéro de série de nœud
d’autres jetons spécifiques du noeud

L’identifiant d’interface unique dans un préfixe de sous-réseau devrait être généré d’une façon qui reste intangible après une réinitialisation si un nœud ou si des interfaces sont ajoutés ou supprimés à partir du nœud.

Le choix de l’algorithme approprié dépend de la liaison et de la mise en œuvre. Les détails de la formation des identifiants d’interface sont définis dans la spécification "IPv6 sur <liaison>" appropriée. Il est vivement recommandé qu’un algorithme de détection de collision soit mis en œuvre au titre de tout algorithme automatique.

Note : [EUI-64] définit en réalités 0xFF et 0xFF comme étant les bits à insérer pour créer un identifiant IEEE EUI-64 à partir d’un identifiant IEEE MAC-48. Les valeurs 0xFF et 0xFE sont utilisées lorsque on commence avec un identifiant IEEE EUI-48. La valeur incorrecte a été utilisées dans les précédentes versions de la spécification à cause d’un malentendu sur la différences entre identifiants IEEE MAC-48 et EUI-48.

Le présent document continue à dessein d’utiliser 0xFF et 0xFE parce que cela satisfait aux exigences pour les identifiant d’interface IPv6 (c’est-à-dire, qu’ils doivent être uniques sur la liaison) parce que les identifiants IEEE EUI-48 et MAC-48 sont syntaxiquement équivalents, et que cela ne pose aucun problème pratique.

Appendice B	Changements par rapport à la RFC 3513

Les changements suivants ont été apportées depuis la RFC3513, "Architecture d’adressage IP Version 6" :

o	Les restrictions à l’utilisation d’adresses IPv6 d’envoi à la cantonade ont été retirées parce qu’on a maintenant une expérience suffisante de l’utilisation des adresses d’envoi à la cantonade, dont le problème n’est pas spécifique de IPv6, et sur lequel portent les efforts du groupe de travail GROW.

o	Préfixe de site local en envoi individuel déconseillé. Les changements portent sur :
-	le retrait du site local de la liste des préfixes spéciaux du paragraphe 2.4,
-	le partage du paragraphe intitulé "Adresses IPv6 en envoi individuel d’utilisation locale" en deux paragraphes, "Adresses IPv6 en envoi individuel de liaison locale" et "Adresses IPv6 en envoi individuel de site local",
-	Ajout de texte au nouveau paragraphe qui décrit pourquoi le site local est déconseillé.

o	Changements pour résoudre les questions soulevées par la réponse de l’IAB à l’appel de Robert Elz. Les changements incluent ce qui suit :
-	Ajout de la précision au paragraphe 2.5 que les nœuds ne devraient pas faire de suppositions sur la structure d’une adresse IPv6,
-	Changement du texte du paragraphe 2.5.1 et de l’appendice A pour se référer to aux identifiants modifiés d’interface de format EUI-64 avec le bit "u" établi à un (1) pour universel.
-	Ajout de la précision au paragraphe 2.5.1 que les nœuds IPv6 ne sont pas obligés de valider que les identifiants d’interface créés dans le format modifié EUI-64 avec le bit "u" établi à un sont uniques.

o	Changement de la référence indiquée au paragraphe 2.5.4 "Adresses d’envoi individuel mondiales" à la RFC3587.

o	Retrait de la mention des adresses NSAP dans les exemples.

o	Précision que le "x" dans la représentation textuelle peut être un nombre de un à quatre chiffres.

o	L’adresse compatible Ipv6 est déconseillée parce qu’elle n’est pas utilisée dans les mécanismes de transition vers IPv6.

o	Ajout des fanions "R" et "P" au paragraphe 2.7 sur les adresses de diffusion groupée, et pointeurs sur les documents qui les définissent.

o	Changements rédactionnel.

Adresse des auteurs

Robert M. Hinden	Stephen E. Deering	
Nokia	Cisco Systems, Inc.	
313 Fairchild Drive	170 West Tasman Drive	
Mountain View, CA 94043	San Jose, CA 95134-1706	
USA	USA	
téléphone : +1 650 625-2004		
mél : bob.hinden@nokia.com		

Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (2005).

Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, et à www.rfc-editor.org, et sauf pour ce qui est mentionné ci-après, les auteurs conservent tous leurs droits.

Le présent document et les informations qui y sont contenues sont fournies sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations ci encloses ne violent aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

Propriété intellectuelle
L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourraient être revendiqués au titre de la mise en œuvre ou l’utilisation de la technologie décrite dans le présent document ou sur la mesure dans laquelle toute licence sur de tels droits pourrait être ou n’être pas disponible ; pas plus qu’elle ne prétend avoir accompli aucun effort pour identifier de tels droits. Les informations sur les procédures de l’ISOC au sujet des droits dans les documents de l’ISOC figurent dans les BCP 78 et BCP 79.

Des copies des dépôts d’IPR faites au secrétariat de l’IETF et toutes assurances de disponibilité de licences, ou le résultat de tentatives faites pour obtenir une licence ou permission générale d’utilisation de tels droits de propriété par ceux qui mettent en œuvre ou utilisent la présente spécification peuvent être obtenues sur le répertoire en ligne des IPR de l’IETF à http://www.ietf.org/ipr.

L’IETF invite toute partie intéressée à porter son attention sur tous droits de reproduction, licences ou applications de licence, ou autres droits de propriété qui pourraient couvrir les technologies qui peuvent être nécessaires pour mettre en œuvre la présente norme. Prière d’adresser les informations à l’IETF à ietf- ipr@ietf.org.

Remerciement 
Le financement de la fonction d’édition des RFC est actuellement fourni par la Internet Society.