RFC3484

page - 1 Groupe de travail Rseau

Request for Comments : 3484
Catgorie : En cours de normalisation

Draves
R. Draves, Microsoft Research
fvrier 2003
Traduction Claude Brire de LIsle

Choix dadresse par dfaut pour le protocole Internet version 6 (IPv6)

Statut du prsent mmoire
Le prsent document spcifie un protocole de lInternet en cours de normalisation pour la communaut de lInternet, et
appelle des discussions et suggestions pour son amlioration. Prire de se rfrer ldition en cours des "Protocoles
officiels de lInternet" (STD 1) pour voir ltat de normalisation et le statut de ce protocole. La distribution du prsent
mmoire nest soumise aucune restriction.
Notice de Copyright
Copyright (C) The Internet Society (2003). Tous droits rservs.
Rsum
Le prsent document dcrit deux algorithmes, pour le choix dadresse de source et pour le choix dadresse de destination.
Les algorithmes spcifient un comportement par dfaut pour toutes les mises en uvre du protocole Internet version 6
(IPv6). Ils noutrepassent pas les choix faits par les applications ou les protocoles de couche suprieure, ni nempchent le
dveloppement de mcanismes plus avancs de choix dadresse. Les deux algorithmes partagent un contexte commun,
incluant un mcanisme facultatif qui permet aux administrateurs de fournir la politique qui peut outrepasser le
comportement par dfaut. Dans les mises en uvre de double pile de protocoles, lalgorithme de choix dadresse de
destination peut prendre en considration aussi bien les adresses IPv4 que IPv6 selon les adresses de source disponibles,
lalgorithme peut prfrer les adresses IPv6 aux adresses IPv4, ou vice-versa.
Tous les nuds IPv6, y compris les htes et les routeurs, doivent mettre en uvre le choix dadresse par dfaut comme
dfini dans la prsente spcification.

Table des matires

1. Introduction............................................................................................................................................................................2
1.1 Conventions utilises dans ce document........................................................................................................................2
2. Contexte du fonctionnement des algorithmes........................................................................................................................2
2.1 Tableau de politique.......................................................................................................................................................3
2.2 Longueur de prfixe commun.........................................................................................................................................4
3. Proprits dadresse................................................................................................................................................................4
3.1 Comparaisons de porte..................................................................................................................................................4
3.2 Adresses IPv4 et adresses transposes en IPv4..............................................................................................................4
3.3 Autres adresses IPv6 avec adresses IPv4 incorpores....................................................................................................5
3.4 Adresses de bouclage IPv6 et autres prfixes de format................................................................................................5
3.5 Adresses de mobilit.......................................................................................................................................................5
4. Adresses de source candidates...............................................................................................................................................5
5. Choix dadresse de source......................................................................................................................................................6
6. Choix dadresse de destination...............................................................................................................................................7
7. Interactions avec lacheminement..........................................................................................................................................8
8. Considrations de mise en uvre...........................................................................................................................................9
9. Considrations pour la scurit..............................................................................................................................................9
10. Exemples..............................................................................................................................................................................9
10.1 Choix dadresse de source par dfaut.........................................................................................................................10
10.2 Choix dadresse de destination par dfaut..................................................................................................................10
10.3 Configuration de la prfrence pour IPv6 ou IPv4.....................................................................................................11
10.4 Configuration de la prfrence pour des adresses porte limite............................................................................11
10.5 Configuration dun site multi rattachements..............................................................................................................12
Rfrences................................................................................................................................................................................13
Remerciements.........................................................................................................................................................................14
Adresse de lauteur...................................................................................................................................................................14
Dclaration complte de droits de reproduction.......................................................................................................................14

RFC3484

page - 2 -

1.

Introduction

Larchitecture dadressage IPv6 [RFC2373] permet que plusieurs adresses denvoi individuel soient alloues aux interfaces.
Ces adresses peuvent avoir des portes daccessibilit diffrentes (liaison locale, site local, ou mondiales). Ces adresses
peuvent aussi tre "prfres" ou "dconseilles" [RFC2462]. Les considrations de confidentialit ont introduit les
concepts de "adresses publiques" et "adresses temporaires" [RFC3041]. Larchitecture de mobilit introduit les "adresses de
rattachement" et "adresses dentretien" [RFC3775]. De plus, les situations de multi rattachement vont rsulter en plus
dadresses par nud. Par exemple, un nud peut avoir plusieurs interfaces, dont certaines sont des tunnels ou des interfaces
virtuelles, ou un site peut avoir plusieurs rattachements de FAI (fournisseur dadresse Internet) avec un prfixe mondial par
FAI.
Le rsultat final est que les mises en uvre de IPv6 vont trs souvent se trouver en face de plusieurs adresses de source et
de destination possibles lors de linitiation dune communication. Il est souhaitable davoir des algorithmes par dfaut,
communs toutes les mises en uvre, pour choisir les adresses de source et de destination afin que les dveloppeurs et les
administrateurs puissent rflchir sur, et prdire, le comportement de leurs systmes.
De plus, des mises en uvre de piles duelles ou hybrides, qui prennent en charge la fois IPv6 et IPv4, vont trs souvent
avoir besoin de choisir entre IPv6 et IPv4 lors de linitiation de la communication. Par exemple, quand la rsolution de
noms du DNS donne la fois des adresses IPv6 et IPv4 et que la pile de protocoles rseau a disponibles la fois des
adresses de source IPv6 et IPv4. Dans de tels cas, une simple politique de toujours prfrer IPv6 ou de toujours prfrer
IPv4 peut produire un mauvais comportement. Par exemple, supposons quun nom du DNS se rsolve en une adresse IPv6
mondiale et une adresse IPv4 mondiale. Si le nud a allou une adresse IPv6 mondiale et une adresse IPv4 auto-configure
169.254/16 [RFC3927], alors IPv6 est le meilleur choix pour la communication. Mais si le nud a allou seulement une
adresse IPv6 de liaison locale et une adresse IPv4 mondiale, alors IPv4 est le meilleur choix pour la communication.
Lalgorithme de choix dadresse de destination rsout cela avec une procdure unifie pour choisir entre les deux adresses
IPv6 et IPv4.
Les algorithmes du prsent document sont spcifis comme un ensemble de rgles qui dfinissent un ordre partiel sur
lensemble des adresses qui sont disponibles lutilisation. Dans le cas du choix dadresse de source, un nud a
normalement plusieurs adresses alloues ses interfaces, et les rgles dordre des adresses de source de la section 5
dfinissent quelle adresse est la "meilleure" utiliser. Dans le cas de choix dadresse de destination, le DNS peut retourner
un ensemble dadresses pour un certain nom, et une application a besoin de dcider laquelle utiliser dabord, et dans quel
ordre essayer les autres si la premire nest pas accessible. Les rgles dordre dadresse de destination de la section 6,
lorsque elles sont appliques lensemble dadresses retourn par le DNS, fournissent un tel ordre recommand.
Le prsent document spcifie sparment le choix dadresse de source et le choix dadresse de destination, mais en utilisant
un contexte commun de sorte quensemble les deux algorithmes donnent des rsultats utiles. Les algorithmes essayent de
choisir des adresses de source et de destination de porte et dtat de configuration appropri (prfr ou dconseill au
sens de la RFC2462). De plus, le prsent document suggre une mthode prfre, du plus long prfixe correspondant, pour
choisir parmi les adresses par ailleurs quivalentes en labsence de meilleures informations. Le prsent document spcifie
aussi des astuces de politique pour permettre un outrepassement administratif du comportement par dfaut. Par exemple, en
utilisant ces astuces, un administrateur peut spcifier un prfixe de source prfr utiliser avec un prfixe de destination,
ou prfrer des adresses de destination avec un prfixe des adresses avec un autre prfixe. Ces astuces donnent
ladministrateur de la souplesse pour traiter certains scnarios de multi rattachement et de transition, mais ils ne sont
certainement pas une panace.
Les rgles de choix spcifies dans le prsent document NE DOIVENT PAS tre construites pour outrepasser le choix
explicite dune application ou dune couche suprieure dune adresse lgale de destination ou de source.
1.1
Conventions utilises dans ce document
Les mots cls "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS",
"RECOMMAND", "PEUT", et "FACULTATIF" dans ce document sont interprter comme dcrit dans le BCP 14,
[RFC2119].

2.

Contexte du fonctionnement des algorithmes

Notre contexte pour les choix dadresse dcoule de larchitecture de mise en uvre la plus courante, qui spare le choix de
ladresse de destination du choix de ladresse de source. Par consquent, nous avons deux algorithmes distincts pour ces
tches. Les algorithmes sont conus pour bien fonctionner ensemble et ils partagent un mcanisme pour loutrepassement
de politique administrative.

Draves

RFC3484

page - 3 Dans cette architecture de mise en uvre, les applications utilisent des API [RFC2553] comme getaddrinfo() qui retournent
une liste dadresses lapplication. Cette liste peut contenir des adresses aussi bien IPv6 que IPv4 (parfois reprsentes par
des adresses transposes en IPv4). Lapplication passe alors une adresse de destination la pile rseau avec connect() ou
sendto(). Lapplication va alors normalement essayer la premire adresse de la liste, dcrivant la liste dadresses jusqu
trouver une adresse qui convienne. Dans tous les cas, la couche rseau nest jamais en situation davoir besoin de choisir
une adresse de destination entre plusieurs solutions de remplacement. Lapplication peut aussi spcifier une adresse de
source avec bind(), mais souvent ladresse de source est laisse non spcifie. Donc, la couche rseau choisit souvent une
adresse de source entre plusieurs choix.
Par consquent, il est prvu que les mises en uvre de getaddrinfo() utilisent lalgorithme de choix dadresse de destination
spcifi ici pour trier la liste des adresses IPv6 et IPv4 quelles retournent. De son ct, la couche rseau IPv6 va utiliser
lalgorithme de choix dadresse de source lorsque une application ou couche suprieure na pas spcifi dadresse de
source. Lapplication de la prsente spcification au choix dadresse de source dans une couche rseau IPv4 est peut-tre
possible mais cela na pas t explor plus avant ici.
Les applications qui se comportent bien DEVRAIENT itrer travers la liste dadresses retourne de getaddrinfo() jusqu
ce quelles trouvent une adresse qui fonctionne.
Les algorithmes utilisent plusieurs critres pour prendre leurs dcisions. Leffet combin est de prfrer les paires
dadresse destination/source pour lesquelles les deux adresses sont de porte ou type gal, de prfrer les plus petites
portes aux plus grandes pour ladresse de destination, de prfrer les adresses de source non dconseilles, dviter
dutiliser des adresses transitoires lorsque les adresses natives sont disponibles, et toutes choses gales par ailleurs, de
prfrer les paires dadresse qui ont le plus long prfixe commun possible. Pour le choix dadresse de source, les adresses
publiques [RFC3041] sont prfres aux adresses temporaires. Dans les situations mobiles [RFC3775], les adresses de
rattachement sont prfres aux adresses dentretien. Si une adresse est simultanment une adresse de rattachement et une
adresse dentretien (ce qui indique que le nud mobile est "a la maison" pour cette adresse) alors ladresse de
rattachement/dentretien est prfre aux adresses qui sont seulement une adresse de rattachement ou seulement une
adresse dentretien.
La prsente spcification permet en option la possibilit dune configuration administrative de politique qui puisse
outrepasser le comportement par dfaut des algorithmes. Loutrepassement de politique prend la forme dun tableau
configurable qui spcifie les valeurs de prsance et les prfixes de source prfrs pour les prfixes de destination. Si une
mise en uvre nest pas configurable, ou si une mise en uvre na pas t configure, alors le tableau de politique par
dfaut spcifi dans le prsent document DEVRAIT tre utilis.
2.1
Tableau de politique
Le tableau de politique est un tableau de recherche de la plus longue correspondance de prfixe, un peu comme un tableau
dacheminement. tant donne une adresse A, une recherche dans le tableau de politique produit deux valeurs : une valeur
de prsance Precedence(A) et un classement ou tiquette Label(A). La valeur de prsance Precedence(A) est utilise pour
trier les adresses de destination. Si Precedence(A) > Precedence(B), on dit que ladresse A a une plus forte prsance que
ladresse B, ce qui signifie que notre algorithme va prfrer trier ladresse de destination A avant ladresse de destination B.
La valeur dtiquette Label(A) permet des politiques qui prfrent utiliser un prfixe particulier dadresse de source avec un
prfixe dadresse de destination. Les algorithmes prfrent utiliser ladresse de source S avec une adresse de destination D
si Label(S) = Label(D). Les mises en uvre de IPv6 DEVRAIENT prendre en charge le choix dadresse configurable via
un mcanisme au moins aussi puissant que les tableaux de politique dfinis ici. Noter quau moment de la rdaction du
prsent document, il ny a que peu dexprience dutilisation de politiques qui choisissent partir dun ensemble possible
dadresses IPv6. Lorsque on aura plus dexprience, les politiques par dfaut recommandes pourront changer. Par
consquent, il est important que les mises en uvre fournissent un moyen de changer les politiques par dfaut lorsque plus
dexprience aura t obtenue. Les paragraphes 10.3 et 10.4 donnent des exemples des sortes de changements qui
pourraient tre ncessaires.
Si une mise en uvre nest pas configurable ou na pas t configure, elle DEVRAIT alors fonctionner conformment aux
algorithmes spcifis ici en conjonction avec le tableau de politique par dfaut suivant :
Prfixe
Prsance
::1/128
50
::/0
40
2002::/16
30
::/96
20
::ffff:0:0/96
10

tiquette
0
1
2
3
4

Draves

RFC3484

page - 4 Un effet du tableau de politique par dfaut est de prfrer utiliser les adresses de source natives avec des adresses de
destination natives, des adresses de source 64 [RFC3056] avec des adresses de destination 64, et des adresses de source
compatibles v4 [RFC2373] avec des adresses de destination compatibles v4. Un autre effet du tableau de politique par
dfaut est de prfrer la communication qui utilise des adresses IPv6 la communication qui utilise des adresses IPv4, si
les adresses de source correspondantes sont disponibles.
Les entres de tableau de politique pour les prfixes dadresse porte limite PEUVENT tre qualifies avec un indice de
zone facultatif. Si il en est ainsi, une entre de tableau de prfixes est seulement confronte une adresse durant une
recherche si lindice de zone correspond aussi lindice de zone de ladresse.
2.2
Longueur de prfixe commun
On dfinit la longueur du prfixe commun CommonPrefixLen(A, B) de deux adresses A et B comme la longueur du plus
long prfixe (en regardant les bits de plus fort poids, ou les plus gauche) que les deux adresses ont en commun. Elle va de
0 128.

3.

Proprits dadresse

Dans les rgles donnes dans les paragraphes qui suivent, les adresses de diffrents types (par exemple, IPv4, IPv6,
diffusion groupe et envoi individuel) sont compares les unes par rapport aux autres. Certains de ces types dadresse ont
des proprits qui ne sont pas directement comparables aux autres. Par exemple, les adresses IPv6 denvoi individuel
peuvent tre "prfres" ou "dconseilles" [RFC2462], alors que les adresses IPv4 nont pas une telle notion. Les
transpositions suivantes sont dfinies pour comparer de telles adresses en utilisant les rgles de classement (par exemple,
pour utiliser des adresses "prfres" de prfrence des adresses "dconseilles").
3.1
Comparaisons de porte
Les adresses de destination de diffusion groupe ont un champ de porte de quatre bits qui contrle la propagation du
paquet en diffusion groupe. Larchitecture dadressage IPv6 dfinit des valeurs du champ Porte pour les portes
dinterface locale (0x1), de liaison locale (0x2), de sous-rseau local (0x3), dadministration locale (0x4), de site local
(0x5), dorganisation locale (0x8), et mondiale (0xE) [RFC3513].
Lutilisation de lalgorithme de choix dadresse de source en prsence dadresses de destination en diffusion groupe exige
la comparaison de la porte dune adresse denvoi individuel avec la porte dune adresse de diffusion groupe. On
transpose une porte de liaison locale en envoi individuel en porte de liaison locale en diffusion groupe, de site local en
envoi individuel en site local en diffusion groupe, et de porte mondiale en envoi individuel en porte mondiale en
diffusion groupe. Par exemple, le site local en envoi individuel est gal au site local en diffusion groupe, qui est plus petit
que lorganisation locale en diffusion groupe, qui est plus petit que le mondial en envoi individuel, qui est gal au mondial
en diffusion groupe.
On crit Scope(A) pour signifier la porte de ladresse A. Par exemple, si A est une adresse denvoi individuel de porte
liaison locale et si B est une adresse de diffusion groupe de porte de site local, alors Scope(A) < Scope(B).
Cette transposition fusionne implicitement les frontires de site denvoi individuel et les frontires de site de diffusion
groupe [RFC3513]].
3.2
Adresses IPv4 et adresses transposes en IPv4
Le choix dun algorithme dadresse de destination fonctionne aussi bien sur les adresses IPv6 que IPv4. cette fin, les
adresses IPv4 devraient tre reprsente comme des adresses transposes en IPv4 [RFC2373]. Par exemple, pour
rechercher la prsance sur dautres attributs dune adresse IPv4 dans le tableau de politique, pour rechercher ladresse
IPv6 correspondant celle transpose en IPv4.
Les adresses IPv4 ont des portes qui sont alloues comme suit. Les adresses IPv4 auto-configures [RFC3927], qui ont le
prfixe 169.254/16, ont une porte alloue de liaison locale. Les adresses prives IPv4 [RFC1918], qui ont les prfixes
10/8, 172.16/12, et 192.168/16, ont une porte alloue de site local. Les adresses de bouclage IPv4 du paragraphe 4.2.2.11
de la [RFC1918], qui ont le prfixe 127/8, ont une porte alloue de liaison locale (de faon analogue au traitement de
ladresse de bouclage IPv6 de la section 4 de la [RFC3513]). Les autres adresses IPv4 ont une porte alloue mondiale.
Les adresses IPv4 devraient tre traites comme ayant ltat de configuration "prfr" (au sens de la RFC2462).

Draves

RFC3484

page - 5 -

3.3
Autres adresses IPv6 avec adresses IPv4 incorpores
Les adresses compatibles IPv4 [RFC2373], transposes IPv4 [RFC2373], traduisibles en IPv4 [RFC2765] et les adresses
64 [RFC3056] contiennent une adresse IPv4 incorpore. Pour les besoins du prsent document, ces adresses devraient tre
traites comme ayant une porte mondiale.
Les adresses compatibles IPv4, transposes en IPv4, et traduisibles en IPv4 devraient tre traites comme ayant le statut de
configuration de "prfr" (au sens de la RFC2462).
3.4
Adresses de bouclage IPv6 et autres prfixes de format
Ladresse de bouclage devrait tre traite comme ayant une porte de liaison locale [RFC3513, section 4] et ltat de
configuration "prfr" (au sens de la RFC2462).
Les adresses NSAP et autres adresses avec des prfixes de format encore indfini devraient tre traites comme ayant une
porte mondiale et un tat de configuration de "prfr" (au sens de la RFC2462). Des normes ultrieures pourront
outrepasser ce traitement.
3.5
Adresses de mobilit
Certains nuds peuvent prendre en charge la mobilit en utilisant les concepts dadresse de rattachement et dadresse
dentretien (par exemple, voir la [RFC3775]). Du point de vue conceptuel, une adresse de rattachement est une adresse IP
alloue un nud mobile et utilise comme adresse permanente du nud mobile. Une adresse dentretien est une adresse
IP associe un nud mobile lorsque il visite une liaison trangre. Lorsque un nud mobile est sur sa liaison de
rattachement, il peut avoir une adresse qui soit simultanment une adresse de rattachement et une adresse dentretien.
Pour les besoins du prsent document, il est suffisant de savoir si ses propres adresses sont ou non conues comme des
adresses de rattachement ou des adresses dentretien. La question de savoir si une adresse devrait tre vue comme une
adresse de rattachement ou une adresse dentretien sort du domaine dapplication du prsent document.

4.

Adresses de source candidates

Lalgorithme de choix dadresse de source utilise le concept dun "ensemble candidat" dadresses de source potentielles
pour une certaine adresse de destination. Lensemble candidat est lensemble de toutes les adresses qui pourraient tre
utilises comme adresse de source ; lalgorithme de choix dadresse de source va prendre une adresse dans cet ensemble.
On crit CandidateSource(A) pour noter lensemble candidat pour ladresse A.
Il est RECOMMAND que les adresses de source candidates soient lensemble des adresses denvoi individuel alloues
linterface qui sera utilis pour envoyer la destination (linterface "sortante"). Sur les routeurs, lensemble candidat PEUT
inclure les adresses denvoi individuel alloues tout interface qui transmet les paquets, sous rserve des restrictions
dcrites ci-dessous.
Discussion : Le mcanisme Redirect de la dcouverte de voisin de la [RFC2461] exige que les routeurs vrifient que
ladresse de source dun paquet identifie un voisin avant de gnrer un Redirect, de sorte quil est avantageux pour les
htes de choisir des adresses de source alloues linterface sortante. Les mises en uvre qui souhaitent prendre en charge
lutilisation dadresses de source mondiales alloues une interface de bouclage devraient se comporter comme si
linterface de bouclage gnrait et transmettait le paquet.
Dans certains cas, ladresse de destination peut tre qualifie avec un indice de zone ou dautres informations qui vont
contraindre lensemble candidat.
Pour les adresses de destination de diffusion groupe et de liaison locale, lensemble des adresses de source candidates
DOIT seulement inclure des adresses alloues aux interfaces qui appartiennent la mme liaison que linterface sortante.
Discussion : La restriction aux adresses de destination en diffusion groupe est ncessaire parce que les algorithmes de
transmission de diffusion groupe actuellement dploys utilisent des vrifications de transmission sur le chemin inverse
(RPF, Reverse Path Forwarding).
Pour les adresses de destination de site local, lensemble des adresses de source candidates DOIT inclure seulement les

Draves

RFC3484

page - 6 adresses alloues aux interfaces qui appartiennent au mme site que linterface sortante.
En aucun cas, les adresses denvoi la cantonade, les adresses de diffusion groupe, et ladresse non spcifie NE
DOIVENT tre incluses dans un ensemble candidat.
Si une application ou couche suprieure spcifie une adresse de source qui nest pas dans lensemble candidat pour la
destination, la couche rseau DOIT alors traiter cela comme une erreur. Ladresse de source spcifie peut influencer
lensemble candidat en affectant le choix de linterface sortante. Si lapplication ou couche suprieure spcifie une adresse
de source qui est dans lensemble candidat pour la destination, la couche rseau DOIT alors respecter ce choix. Si
lapplication ou couche suprieure ne spcifie pas dadresse de source, la couche rseau utilise alors lalgorithme de choix
dadresse de source spcifi au paragraphe suivant.
Sur les nuds IPv6 seul qui prennent en charge SIIT [RFC2765, en particulier la section 5], si ladresse de destination est
une adresse transpose en IPv4, lensemble candidat DOIT alors ne contenir que des adresses traduisibles en IPv4. Si
ladresse de destination nest pas une adresse transpose en IPv4, lensemble candidat NE DOIT alors PAS contenir
dadresse traduisible en IPv4.

5.

Choix dadresse de source

Lalgorithme de choix dadresse de source produit comme rsultat une seule adresse de source utiliser avec une certaine
adresse de destination. Cet algorithme ne sapplique quaux adresses de destination IPv6, pas aux adresses IPv4.
Lalgorithme est spcifi ici en termes de liste de rgles de comparaison de paires qui (pour une certaine adresse de
destination D) imposent un ordre de "suprieur " aux adresses de lensemble candidat CandidateSource(D). Ladresse en
tte de la liste lachvement de lalgorithme est celle quil a retenue.
Noter que conceptuellement, un tri de lensemble de candidats est effectu dans lequel un ensemble de rgles dfinit lordre
des adresses. Mais comme le rsultat de lalgorithme est une seule adresse de source, une mise en uvre na pas besoin en
ralit de trier lensemble ; elle a seulement besoin didentifier la valeur "maximum" qui termine en tte de la liste trie.
Lordre des adresses dans lensemble candidat est dfini par une liste de huit rgles de comparaison par paires, chaque rgle
plaant un ordre "suprieur ", "infrieur ", ou "gal ", sur deux adresses de source lune par rapport lautre (et par
rapport cette rgle). Dans le cas o une certaine rgle produit une galit, cest--dire donne un rsultat "gal " pour les
deux adresses, les rgles restantes sont appliques (dans lordre) pour les seules adresses qui sont galit pour les
dpartager. Noter que si une rgle produit un seul clair "vainqueur" (ou ensemble de "vainqueurs" dans le cas dgalit) les
adresses qui ne sont pas dans lensemble vainqueur peuvent tre limines des calculs suivants, les rgles suivantes ntant
appliques quaux adresses restantes. Si les huit rgles chouent choisir une seule adresse, un moyen de dpartage non
spcifi devrait tre utilis.
Quand on compare deux adresses SA et SB de lensemble candidat, on dit "prfrer SA" pour signifier que SA est
"suprieur " SB, et de faon similaire, on dit "prfrer SB" pour signifier que SA est "infrieur " SB.
Rgle 1 : Prfrer la mme adresse.
Si SA = D, alors prfrer SA. De mme, si SB = D, alors prfrer SB.
Rgle 2 : Prfrer la porte approprie.
Si Scope(SA) < Scope(SB) : Si Scope(SA) < Scope(D), alors prfrer SB et autrement prfrer SA. De mme, si
Scope(SB) < Scope(SA) : Si Scope(SB) < Scope(D), alors prfrer SA et autrement prfrer SB.
Rgle 3 : viter les adresses dconseilles.
Les adresses SA et SB ont la mme porte. Si une des deux adresses de source est "prfre" et si lune delles est
"dconseille" (au sens de la RFC2462) prfrer alors celle qui est "prfre".
Rgle 4 : Prfrer les adresses de rattachement.
Si SA est simultanment une adresse de rattachement et une adresse dentretien et si SB ne lest pas, prfrer SA. De
mme, si SB est simultanment une adresse de rattachement et une adresse dentretien et si SA ne lest pas, alors, prfrer
SB. Si SA est juste une adresse de rattachement et si SB est juste une adresse dentretien, alors prfrer SA. De mme, si
SB est juste une adresse de rattachement et si SA est juste une adresse dentretien, alors prfrer SB.
Les mises en uvre devraient fournir un mcanisme qui permette une application dinverser le sens de cette prfrence et
de prfrer les adresses dentretien plutt que les adresses de rattachement (par exemple, via des extensions dAPI

Draves

RFC3484

page - 7 appropries). Lutilisation de ce mcanisme ne devrait affecter que les rgles de choix pour lapplication invocatrice.
Rgle 5 : Prfrer linterface sortante.
Si SA est allou linterface qui sera utilise pour envoyer D et si SB est allou une interface diffrente, alors prfrer
SA. De mme, si SB est allou linterface qui sera utilise pour envoyer D et si SA est allou une interface diffrente,
alors prfrer SB.
Rgle 6 : Prfrer ltiquette qui correspond.
Si Label(SA) = Label(D) et si Label(SB) <> Label(D), alors prfrer SA. De mme, si Label(SB) = Label(D) et si
Label(SA) <> Label(D), alors prfrer SB.
Rgle 7 : Prfrer les adresses publiques.
Si SA est une adresse publique et si SB est une adresse temporaire, alors prfrer SA. De mme, si SB est une adresse
publique et si SA est une adresse temporaire, alors prfrer SB.
Les mises en uvre DOIVENT fournir un mcanisme permettant une application dinverser le sens de cette prfrence et
de prfrer les adresses temporaires aux adresses publiques (par exemple, via les extensions dAPI appropries).
Lutilisation du mcanisme devrait naffecter que les rgles de choix pour lapplication invocatrice. Cette rgle vite de
possibles checs des applications du fait de la dure de vie relativement courte des adresses temporaires ou cause de la
possibilit que la recherche inverse dune adresse temporaire nchoue ou retourne un nom alatoire. Les mises en uvre
pour lesquelles les considrations de confidentialit lemportent sur les soucis de compatibilit de ces applications
PEUVENT inverser le sens de cette rgle et prfrer par dfaut les adresses temporaires aux adresses publiques.
Rgle 8 : Utiliser le prfixe qui a la plus longue correspondance.
Si CommonPrefixLen(SA, D) > CommonPrefixLen(SB, D), alors prfrer SA. De mme, si CommonPrefixLen(SB, D) >
CommonPrefixLen(SA, D), alors prfrer SB.
La rgle 8 peut tre outrepasse si la mise en uvre a dautres moyens de choisir entre les adresses de source. Par exemple,
si la mise en uvre sait plus ou moins quelle adresse de source va rsulter en les "meilleures" performances de
communication.
La rgle 2 (prfrer la porte approprie) DOIT tre mise en uvre et recevoir une priorit leve parce quelle peut
affecter linteroprabilit.

6.

Choix dadresse de destination

Lalgorithme de choix dadresse de destination prend une liste dadresses de destination et trie les adresses pour produire
une nouvelle liste. Il est spcifi ici sous la forme de la comparaison dune paire dadresses DA et DB, o DA apparat
avant DB dans la liste originale.
Lalgorithme trie ensemble les adresses IPv6 et IPv4. Pour trouver les attributs dune adresse IPv4 dans le tableau de
politique, ladresse IPv4 devrait tre reprsente comme une adresse transpose en IPv4.
On crit Source(D) pour indiquer ladresse de source choisie pour une destination D. Pour les adresses IPv6, le paragraphe
prcdent spcifie lalgorithme de choix dadresse de source. Le choix de ladresse de source pour les adresses IPv4 nest
pas spcifi dans le prsent document.
On dit que Source(D) est indfini si aucune adresse de source nest disponible pour la destination D. Pour les adresses
IPv6, ce nest le cas que si CandidateSource(D) est lensemble vide.
La comparaison par paires des adresses de destination consiste en dix rgles, qui devraient tre appliques dans lordre. Si
une rgle dtermine un rsultat, alors les rgles restantes ne sont pas pertinentes et devraient tre ignores. Les rgles
suivantes agissent comme dpartage pour les rgles prcdentes. Voir la section prcdante une plus longue description
de la faon dont les rgles de dpartage de comparaison par paires peuvent tre utilises pour trier une liste.
Rgle 1 : viter les destinations inutilisables.
Si DB est connu pour tre injoignable ou si Source(DB) est indfini, alors prfrer DA. De mme, si DA est connu pour
tre injoignable ou si Source(DA) est indfini, alors prfrer DB.
Discussion : Une mise en uvre peut savoir quune certaine destination est injoignable de plusieurs faons. Par exemple, la
destination peut tre atteinte travers une interface rseau qui se trouve actuellement dbranche. Par

Draves

RFC3484

page - 8 exemple, la mise en uvre peut conserver pendant un certain temps des informations provenant de la
dtection dinaccessibilit de voisin [RFC2461]. Dans tous les cas, la dtermination dinaccessibilit pour les
besoins de cette rgle dpend de la mise en uvre.
Rgle 2 : Prfrer la porte qui correspond.
Si Scope(DA) = Scope(Source(DA)) et si Scope(DB) <> Scope(Source(DB)), alors prfrer DA. De mme, si Scope(DA)
<> Scope(Source(DA)) et si Scope(DB) = Scope(Source(DB)), alors prfrer DB.
Rgle 3 : viter les adresses dconseilles.Si Source(DA) est dconseille et si Source(DB) ne lest pas, alors prfrer DB.
De mme, si Source(DA) nest pas dconseille et si Source(DB) est dconseill, alors prfrer DA.
Rgle 4 : Prfrer les adresses de rattachement.
Si Source(DA) est simultanment une adresse de rattachement et une adresse dentretien et si Source(DB) ne lest pas, alors
prfrer DA. De mme, si Source(DB) est simultanment une adresse de rattachement et une adresse dentretien et si
Source(DA) ne lest pas, alors prfrer DB.
Si Source(DA) est juste une adresse de rattachement et si Source(DB) est juste une adresse dentretien, alors prfrer DA.
De mme, si Source(DA) est juste une adresse dentretien et si Source(DB) est juste une adresse de rattachement, alors
prfrer DB.
Rgle 5 : Prfrer ltiquette qui correspond.
Si Label(Source(DA)) = Label(DA) et si Label(Source(DB)) <> Label(DB), alors prfrer DA. De mme, si
Label(Source(DA)) <> Label(DA) et si Label(Source(DB)) = Label(DB), alors prfrer DB.
Rgle 6 : Prfrer la plus fore prsance.
Si Precedence(DA) > Precedence(DB), alors prfrer DA. De mme, si Precedence(DA) < Precedence(DB), alors prfrer
DB.
Rgle 7 : Prfrer le transport natif.
Si DA est atteint via un mcanisme de transition encapsulant (par exemple, IPv6 dans IPv4) et si DB ne lest pas, alors
prfrer DB. De mme, si DB est atteint via encapsulation et si DA ne lest pas, alors prfrer DA.
Discussion : 6-sur-4 [RFC2529], ISATAP [RFC4214], et tunnels configurs [RFC1933] sont des exemples de mcanismes
de transition encapsulants pour lesquels ladresse de destination na pas de prfixe spcifique et donc ne peut
recevoir une prsance infrieure dans le tableau de politique. Une mise en uvre PEUT gnraliser cette
rgle en utilisant un concept de prfrence dinterface, et en donnant des interfaces virtuelles (comme les
interfaces encapsulant IPv6 dans IPv4) une prfrence infrieure celle des interfaces natives (comme les
interfaces ethernet).
Rgle 8 : Prfrer la plus petite porte.
Si Scope(DA) < Scope(DB), alors prfrer DA. De mme, si Scope(DA) > Scope(DB), alors prfrer DB.
Rgle 9 : Utiliser le prfixe qui a la plus longue correspondance.
Lorsque DA et DB appartiennent la mme famille dadresses (tous deux sont IPv6 ou tous deux sont IPv4) : si
CommonPrefixLen(DA, Source(DA)) > CommonPrefixLen(DB, Source(DB)), alors prfrer DA. De mme, si
CommonPrefixLen(DA, Source(DA)) < CommonPrefixLen(DB, Source(DB)), alors prfrer DB.
Rgle 10 : Autrement, laisser lordre inchang.
Si DA prcdait DB dans la liste dorigine, prfrer DA. Autrement, prfrer DB.
Les rgles 9 et 10 peuvent tre outrepasses si la mise en uvre a dautres moyens de trier les adresses de destination. Par
exemple, si la mise en uvre sait dune faon ou dune autre quelles adresses de destination vont donner les "meilleures"
performances de communications.

7.

Interactions avec lacheminement

La prsente spcification de choix dadresse de source suppose que lacheminement (plus prcisment, le choix dune
interface sortante sur un nud qui a plusieurs interfaces) est fait avant le choix de ladresse de source. Cependant, les mises
en uvre peuvent utiliser des considrations dadresse de source pour le dpartage lors du choix entre des chemins par
ailleurs quivalents.

Draves

RFC3484

page - 9 Par exemple, supposons quun nud a des interfaces sur deux liaisons diffrentes, les deux liaisons ayant un routeur de
fonctionnement par dfaut. Les deux interfaces ont des adresses mondiales prfres (au sens de la RFC2462). Lorsque on
envoie une adresse de destination mondiale, si il ny a pas de raison lie lacheminement de prfrer une interface
lautre, une mise en uvre peut alors choisir de prfrence linterface sortante qui va lui permettre dutiliser ladresse de
source qui partage un plus long prfixe commun avec la destination.
Les mises en uvre peuvent aussi utiliser le choix du routeur pour influencer le choix de ladresse de source. Par exemple,
supposons un hte sur une liaison avec deux routeurs. Un routeur annonce un prfixe mondial A et lautre routeur annonce
un prfixe mondial B. Lorsque il envoie via le premier routeur, lhte peut prfrer les adresses de source avec le prfixe A
et lorsque il envoie via le second routeur, prfrer les adresses de source avec le prfixe B.

8.

Considrations de mise en uvre

Lalgorithme de choix dadresse de destination a besoin dinformations sur les adresses de source potentielles. Une
stratgie possible de mise en uvre est que getaddrinfo() appelle la couche rseau avec une liste dadresses de destination,
trie la liste dans la couche rseau avec la pleine connaissance actuelle des adresses de source disponibles, et retourne la liste
trie getaddrinfo(). Cest simple et donne le meilleur rsultat mais introduit la surcharge de lappel un autre systme.
Une faon de rduire cette surcharge est de mettre en antmmoire la liste trie des adresses dans le rsolveur, de sorte que
les appels suivants pour le mme nom naient pas besoin de retrier la liste.
Une autre stratgie de mise en uvre est de faire appel la couche rseau pour restituer les informations dadresse de
source et de trier alors la liste des adresses directement dans le contexte de getaddrinfo(). Pour rduire la surcharge dans
cette approche, les informations dadresse de source peuvent tre mises en antmmoire, ce qui amortit la surcharge de la
restitution sur plusieurs appels getaddrinfo(). Dans cette approche, la mise en uvre peut navoir pas connaissance de
linterface sortante pour chaque destination, de sorte quelle PEUT utiliser une dfinition plus lche de lensemble candidat
durant le rangement des adresses de destination.
Dans tous les cas, si la mise en uvre utilise des informations mises en antmmoire et ventuellement primes dans son
application de choix dadresse de destination, ou si le rangement dune liste dadresses de destination en antmmoire
pourrait tre prim, alors elle devrait sassurer que lordre des adresses de destination retourn lapplication nest pas
dpass depuis plus dune seconde. Par exemple, une mise en uvre peut faire un appel systme pour vrifier si des entres
de tableau dacheminement ou des allocations dadresses de source qui pourraient affecter ces algorithmes ont chang. Une
autre stratgie est dutiliser un compteur dinvalidation qui est incrment chaque fois quun tat sous-jacent a chang. En
mettant en antmmoire la valeur actuelle du compteur dinvalidation avec ltat dduite et en comparant ultrieurement
la valeur du moment, la mise en uvre pourra dtecter si ltat dduit est potentiellement prim.

9.

Considrations pour la scurit

Le prsent document na pas dimpact direct sur la scurit de linfrastructure de lInternet.

Noter que la plupart des algorithmes de choix dadresse de source, y compris celui spcifi dans le prsent document,
exposent un souci potentiel de confidentialit. Un nud hostile peut dduire des corrlations entre les adresses dun nud
cible en sondant le nud cible avec des paquets de demande qui forcent lhte cible choisir son adresse de source pour les
paquets de rponse. (Peut-tre parce que les paquets de demande sont envoys une adresse de diffusion groupe ou
denvoi la cantonade, ou peut-tre parce que le protocole de couche suprieure choisi pour lattaque ne spcifie pas une
adresse de source particulire pour ses paquets de rponse.) En utilisant des adresses diffrentes pour lui-mme, le nud
hostile peut causer lexposition des propres adresses du nud cible.

10.

Exemples

La prsente section contient un certain nombre dexemples, dabord de comportement par dfaut et ensuite, dmontrant
lutilit de la configuration dun tableau de politiques. Ces exemples ne sont fournis qu titre dillustration ; ils ne
devraient pas tre considrs comme normatifs.
10.1 Choix dadresse de source par dfaut
Les rgles de choix dadresse de source, en conjonction avec le tableau de politique par dfaut, produisent le comportement
suivant :

Draves

RFC3484

page - 10 Destination: 2001::1

Adresses sources candidates : 3ffe::1 ou fe80::1
Rsultat : 3ffe::1 (prfrer la porte approprie)
Destination: 2001::1
Adresses sources candidates : fe80::1 ou fec0::1
Rsultat : fec0::1 (prfrer la porte approprie)
Destination: fec0::1
Adresses sources candidates : fe80::1 ou 2001::1
Rsultat : 2001::1 (prfrer la porte approprie)
Destination : ff05::1
Adresses sources candidates : fe80::1 ou fec0::1 ou 2001::1Rsultat : fec0::1 (prfrer la porte approprie)
Destination : 2001::1
Adresses sources candidates : 2001::1 (dconseille) ou 2002::1
Rsultat : 2001::1 (prfrer la mme adresse)
Destination : fec0::1
Adresses sources candidates : fec0::2 (dconseille) ou 2001::1
Rsultat : fec0::2 (prfrer la porte approprie)
Destination : 2001::1
Adresses sources candidates : 2001::2 ou 3ffe::2
Rsultat : 2001::2 (plus long prfixe correspondant)
Destination : 2001::1
Adresses sources candidates : 2001::2 (adresse dentretien) ou 3ffe::2 (adresse de rattachement)
Rsultat : 3ffe::2 (prfrer ladresse de rattachement)
Destination : 2002:836b:2179::1
Adresses sources candidates : 2002:836b:2179::d5e3:7953:13eb:22e8 (temporaire) ou 2001::2
Rsultat : 2002:836b:2179::d5e3:7953:13eb:22e8 (prfrer ltiquette correspondante)
Destination : 2001::d5e3:0:0:1
Adresses sources candidates : 2001::2 ou 2001::d5e3:7953:13eb:22e8 (temporaire)
Rsultat : 2001::2 (prfrer ladresse publique)
10.2 Choix dadresse de destination par dfaut
Les rgles de choix dadresse de destination, en conjonction avec le tableau de politique par dfaut et les rgles de choix
dadresse de source, produisent le comportement suivant :
Adresses sources candidates : 2001::2 ou fe80::1 ou 169.254.13.78
Liste dadresses de destination : 2001::1 ou 131.107.65.121
Rsultat : 2001::1 (src 2001::2) puis 131.107.65.121 (src 169.254.13.78) (prfrer la porte qui correspond)
Adresses sources candidates : fe80::1 ou 131.107.65.117
Liste dadresses de destination : 2001::1 ou 131.107.65.121
Rsultat : 131.107.65.121 (src 131.107.65.117) puis 2001::1 (src fe80::1) (prfrer la porte qui correspond)
Adresses sources candidates : 2001::2 ou fe80::1 ou 10.1.2.4
Liste dadresses de destination : 2001::1 ou 10.1.2.3
Rsultat : 2001::1 (src 2001::2) puis 10.1.2.3 (src 10.1.2.4) (prfrer la prsance la plus leve)
Adresses sources candidates : 2001::2 ou fec0::2 ou fe80::2
Liste dadresses de destination : 2001::1 ou fec0::1 ou fe80::1
Rsultat : fe80::1 (src fe80::2) puis fec0::1 (src fec0::2) puis 2001::1 (src 2001::2) (prfrer la plus petite porte)
Adresses sources candidates : 2001::2 (adresse dentretien) ou 3ffe::1 (adresse de rattachement) ou fec0::2 (adresse
dentretien) ou fe80::2 (adresse dentretien)

Draves

RFC3484

page - 11 Liste dadresses de destination : 2001::1 ou fec0::1

Rsultat : 2001:1 (src 3ffe::1) puis fec0::1 (src fec0::2) (prfrer ladresse de rattachement)
Adresses sources candidates : 2001::2 ou fec0::2 (dconseille) ou fe80::2
Liste dadresses de destination : 2001::1 ou fec0::1
Rsultat : 2001::1 (src 2001::2) puis fec0::1 (src fec0::2) (viter les adresses dconseilles)
Adresses sources candidates : 2001::2 ou 3f44::2 ou fe80::2
Liste dadresses de destination : 2001::1 ou 3ffe::1
Rsultat : 2001::1 (src 2001::2) alors 3ffe::1 (src 3f44::2) (plus long prfixe correspondant)
Adresses sources candidates : 2002:836b:4179::2 ou fe80::2
Liste dadresses de destination : 2002:836b:4179::1 ou 2001::1
Rsultat : 2002:836b:4179::1 (src 2002:836b:4179::2) puis 2001::1 (src 2002:836b:4179::2) (prfrer ltiquette
correspondante)
Adresses sources candidates : 2002:836b:4179::2 ou 2001::2 ou fe80::2
Liste dadresses de destination : 2002:836b:4179::1 ou 2001::1
Rsultat : 2001::1 (src 2001::2) puis 2002:836b:4179::1 (src 2002:836b:4179::2) (prfrer la prsance la plus leve)
10.3 Configuration de la prfrence pour IPv6 ou IPv4
Le tableau de politique par dfaut donne aux adresses IPv6 une prsance plus leve quaux adresses IPv4. Cela signifie
que les applications vont utiliser IPv6 de prfrence IPv4 quand les deux sont galement utilisables. Un administrateur
peut changer le tableau de politique pour prfrer les adresses IPv4 en donnant au prfixe ::ffff:0.0.0.0/96 une prsance
plus leve :
Prfixe
::1/128
::/0
2002::/16
::/96
::ffff:0:0/96

Prsance
50
40
30
20
100

tiquette
0
1
2
3
4

Ce changement du tableau de politique par dfaut produit le comportement suivant :

Adresses sources candidates : 2001::2 ou fe80::1 ou 169.254.13.78
Liste dadresses de destination : 2001::1 ou 131.107.65.121
Rsultat inchang : 2001::1 (src 2001::2) puis 131.107.65.121 (src 169.254.13.78) (prfrer la porte qui correspond)
Adresses sources candidates : fe80::1 ou 131.107.65.117
Liste dadresses de destination : 2001::1 ou 131.107.65.121
Rsultat inchang : 131.107.65.121 (src 131.107.65.117) puis 2001::1 (src fe80::1) (prfrer la porte qui correspond)
Adresses sources candidates : 2001::2 ou fe80::1 ou 10.1.2.4
Liste dadresses de destination : 2001::1 ou 10.1.2.3
Nouveau rsultat : 10.1.2.3 (src 10.1.2.4) puis 2001::1 (src 2001::2) (prfrer la prsance la plus leve)
10.4 Configuration de la prfrence pour des adresses porte limite
Les rgles de choix dadresse de destination donnent la prfrence aux destinations de plus petite porte. Par exemple, une
destination de site local sera trie avant une destination de porte mondiale lorsque les deux sont par ailleurs galement
convenables. Un administrateur peut changer le tableau de politique pour inverser cette prfrence et trier les destinations
mondiales avant les destinations de site local, et les destinations de site local avant les destinations de liaison locale :

Draves

RFC3484

page - 12 Prfixe
::1/128
::/0
fec0::/10
fe80::/10
2002::/16
::/96
::ffff:0:0/96

Prsance
50
40
37
33
30
20
10

tiquette
0
1
1
1
2
3
4

Ce changement au tableau de politique par dfaut produit le comportement suivant :

Adresses sources candidates : 2001::2 ou fec0::2 ou fe80::2
Liste dadresses de destination : 2001::1 ou fec0::1 ou fe80::1
Nouveau rsultat : 2001::1 (src 2001::2) puis fec0::1 (src fec0::2) puis fe80::1 (src fe80::2) (prfrer la plus forte prsance)
Adresses sources candidates : 2001::2 (dconseille) ou fec0::2 ou fe80::2
Liste dadresses de destination : 2001::1 ou fec0::1
Rsultat inchang : fec0::1 (src fec0::2) puis 2001::1 (src 2001::2) (viter les adresses dconseilles)
10.5 Configuration dun site multi rattachements
Considrons un site A qui a une relation daffaires importante avec un autre site B. Pour la prise en charge de leurs besoins
daffaires, les deux sites ont contract un service avec des performances trs leves auprs dun FAI. Cest en plus de la
connexion Internet normale que les deux sites ont avec des FAI diffrents. Le FAI hautes performances est coteux et les
deux sites souhaite ne lutiliser que pour leur trafic daffaire le plus important entre eux.
Chaque site a deux prfixes mondiaux, un du FAI hautes performances et un avec le FAI normal. Le site A a le prfixe
2001:aaaa:aaaa::/48 avec le FAI hautes performances et le prfixe 2007:0:aaaa::/48 avec son FAI normal. Le site B a le
prfixe 2001:bbbb:bbbb::/48 avec le FAI hautes performances et le prfixe 2007:0:bbbb::/48 avec son FAI normal. Tous
les htes dans les deux sites ont deux adresses enregistres dans le DNS.
Lacheminement au sein des deux sites dirige la plus grande partie du trafic sur la sortie du FAI normal, mais
lacheminement dirige le trafic envoy au prfixe 2001 de lautre site sur la sortie pour le FAI hautes performances. Pour
empcher lutilisation involontaire de leur connexion avec le FAI hautes performances, les deux sites mettent en uvre un
filtrage dentre pour liminer le trafic entrant en provenance du FAI hautes performances qui ne vient pas de lautre site.
Le tableau de politique par dfaut et les rgles de slection dadresses produisent le comportement suivant :
Adresses sources candidates : 2001:aaaa:aaaa::a ou 2007:0:aaaa::a ou fe80::a
Liste dadresses de destination : 2001:bbbb:bbbb::b ou 2007:0:bbbb::b
Rsultat : 2007:0:bbbb::b (src 2007:0:aaaa::a) puis 2001:bbbb:bbbb::b (src 2001:aaaa:aaaa::a) (prfixe plus longue
correspondance)
En dautre termes, lorsque un hte du site A initie une connexion avec un hte du site B, le trafic ne tire pas parti de leurs
connexions au FAI hautes performances. Ce nest pas le comportement quils dsirent.
Adresses sources candidates : 2001:aaaa:aaaa::a ou 2007:0:aaaa::a ou fe80::a
Liste dadresses de destination : 2001:cccc:cccc::c ou 2006:cccc:cccc::c
Rsultat : 2001:cccc:cccc::c (src 2001:aaaa:aaaa::a) puis 2006:cccc:cccc::c (src 2007:0:aaaa::a) (plus longue
correspondance de prfixe)
En dautres termes, lorsque un hte du site A initie une connexion avec un hte dun autre site C, le trafic inverse peut
revenir par le FAI hautes performances. L encore, ce comportement nest pas dsir.
Cette situation difficile dmontre les limitations de lheuristique de la plus longue correspondance de prfixe dans les
situations de rattachement multiple.
Cependant, les administrateurs des sites A et B peuvent raliser leur comportement dsir par la configuration du tableau de
politique. Par exemple, ils peuvent utiliser le tableau de politique suivant :

Draves

RFC3484

page - 13 Prfixe
Prsance
::1
50
2001:aaaa:aaaa::/48
45
2001:bbbb:bbbb::/48
45
::/0
40
2002::/16
30
::/96
20
::ffff:0:0/96
10

tiquette
0
5
5
1
2
3
4

Ce tableau de politique produit le comportement suivant :

Adresses sources candidates : 2001:aaaa:aaaa::a ou 2007:0:aaaa::a ou fe80::a
Liste dadresses de destination : 2001:bbbb:bbbb::b ou 2007:0:bbbb::b
Nouveau rsultat : 2001:bbbb:bbbb::b (src 2001:aaaa:aaaa::a) puis 2007:0:bbbb::b (src 2007:0:aaaa::a) (prfrer la
prsance la plus leve)
En dautres termes, lorsque un hte du site A initie une connexion avec un hte du site B, le trafic utilise le FAI hautes
performances comme dsir.
Adresses sources candidates : 2001:aaaa:aaaa::a ou 2007:0:aaaa::a ou fe80::a
Liste dadresses de destination : 2001:cccc:cccc::c ou 2006:cccc:cccc::c
Nouveau rsultat : 2006:cccc:cccc::c (src 2007:0:aaaa::a) puis 2001:cccc:cccc::c (src 2007:0:aaaa::a) (plus long prfixe
correspondant)
En dautres termes, lorsque un hte du site A initie une connexion avec un hte dun autre site C, le trafic utilise le FAI
normal comme dsir.

Rfrences
[RFC1812] F. Baker, "Exigences pour les routeurs IP version 4", juin 1995. (Mise jour par la RFC2644)
[RFC1918] Y. Rekhter et autres, "Allocation d'adresse pour les internets privs", BCP 5, fvrier 1996.
[RFC1933] R. Gilligan, E. Nordmark, "Mcanismes de transition pour htes et routeurs IPv6", avril 1996. (Obsolte, voir
RFC4213) (P.S.)
[RFC2026] S. Bradner, "Le processus de normalisation de l'Internet -- Rvision 3", (BCP0009) octobre 1996. (Remplace
RFC1602, RFC1871) (MJ par RFC3667, RFC3668, RFC3932, RFC3979, RFC3978, RFC5378)
[RFC2119] S. Bradner, "Mots cls utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997.
[RFC2373] R. Hinden, S. Deering, "Architecture d'adressage IP version 6", juillet 1998. (Obsolte, voir RFC4291) (P.S.)
[RFC2461] T. Narten, E. Nordmark, W. Simpson, "Dcouverte de voisins pour IP version 6 (IPv6)", dcembre 1998.
(Obsolte, voir RFC4861) (D.S.)
[RFC2462] S. Thomson, T. Narten, "Autoconfiguration d'adresse IPv6 sans tat", dcembre 1998. (Obsolte, voir
RFC4862) (D.S.)
[RFC2529] B. Carpenter, C. Jung, "Transmission d'IPv6 sur des domaines IPv4 sans tunnels explicites", mars 1999.
(P.S.)
[RFC2553] R. Gilligan, S. Thomson, J. Bound, W. Stevens, "Extensions de base d'interface de prise pour IPv6",
mars 1999. (Obsolte, voir RFC3493) (MJ par RFC3152) (Information)
[RFC2765] E. Nordmark, "Algorithme de traduction IP/ICMP sans tat (SIIT)", fvrier 2000. (P.S.)
[RFC3041] T. Narten, R. Draves, "Extensions de confidentialit pour l'auto-configuration d'adresse sans tat dans IPv6",
janvier 2001. (Obsolte, voir RFC4941) (P.S.)
[RFC3056] B. Carpenter, K. Moore, "Connexion des domaines IPv6 via des nuages IPv4", fvrier 2001. (P.S.)
[RFC3513] R. Hinden et S. Deering, "Architecture d'adressage du protocole Internet version 6 (IPv6)", avril 2003.
(Obsolte, remplace par la RFC4291)
[RFC3775] D. Johnson, C. Perkins, J. Arkko, "Prise en charge de la mobilit dans IPv6", juin 2004. (P.S., Obs. voir
RFC6275)
[RFC3927] S. Cheshire, B. Aboba, E. Guttman, "Configuration dynamique des adresses IPv4 de liaison locale",
mai 2005. (P.S.)
[RFC4214] F. Templin et aures, "Protocole d'adressage en tunnel automatique intra-site (ISATAP)", octobre 2005.
(Obsolte, voir RFC5214, Information)

Draves

RFC3484

page - 14 -

Remerciements
Lauteur tient remercier de leurs contributions le groupe de travail IPng et en particulier Marc Blanchet, Brian Carpenter,
Matt Crawford, Alain Durand, Steve Deering, Robert Elz, Jun-ichiro itojun Hagino, Tony Hain, M.T. Hollinger, Jinmei
Tatuya, Thomas Narten, Erik Nordmark, Ken Powell, Markku Savela, Pekka Savola, Hesham Soliman, Dave Thaler,
Mauro Tortonesi, Ole Troan, et Stig Venaas. De plus, les rviseurs anonymes de lIESG ont effectu de nombreux et
importants commentaires et suggestions de prcisions.

Adresse de lauteur
Richard Draves
Microsoft Research
One Microsoft Way
Redmond, WA 98052
USA
tlphone : +1 425 706 2268
ml : richdr@microsoft.com

Dclaration complte de droits de reproduction

Copyright (C) The Internet Society (2003). Tous droits rservs.
Ce document et les traductions de celui-ci peuvent tre copis et diffuss, et les travaux drivs qui commentent ou
expliquent autrement ou aident sa mise en uvre peuvent tre prpars, copis, publis et distribus, partiellement ou en
totalit, sans restriction d'aucune sorte, condition que l'avis de droits de reproduction ci-dessus et ce paragraphe soit inclus
sur toutes ces copies et uvres drives. Toutefois, ce document lui-mme ne peut tre modifi en aucune faon, par
exemple en supprimant le droit d'auteur ou les rfrences l'Internet Society ou d'autres organisations Internet, sauf si c'est
ncessaire l'laboration des normes Internet, auquel cas les procdures pour les droits de reproduction dfinis dans les
processus de normes pour Internet doivent tre suivies, ou si ncessaire pour le traduire dans des langues autres que
l'anglais.
Les permissions limites accordes ci-dessus sont perptuelles et ne seront pas rvoques par la Socit Internet ou ses
successeurs ou ayants droit.
Ce document et les renseignements qu'il contient sont fournis "TELS QUELS" et l'INTERNET SOCIETY et l'INTERNET
ENGINEERING TASK FORCE dclinent toute garantie, expresse ou implicite, y compris mais sans s'y limiter, toute
garantie que l'utilisation de l'information ici prsente n'enfreindra aucun droit ou aucune garantie implicite de
commercialisation ou d'adaptation a un objet particulier.
Remerciement
Le financement de la fonction ddition des RFC est actuellement fourni par la Internet Society.

Draves