1. Introduction
Cette section conserve le texte de la RFC relatif a DHCPv6, notamment les echanges de messages, le comportement des relais, les DUID, IA_NA, IA_TA, IA_PD, les options DHCP, l'authentification RKAP, les registres IANA, les exigences normatives et les matrices d'apparition des options en annexe.
Texte original de la RFC
1. Introduction
Ce document specifie DHCP pour IPv6 (DHCPv6), un protocole
client/serveur qui fournit une configuration geree des equipements.
Le fonctionnement de base de DHCPv6 fournit une configuration aux
clients connectes au meme lien que le serveur. La fonctionnalite
d'agent relais est egalement definie pour permettre la communication
entre des clients et des serveurs qui ne se trouvent pas sur le meme
lien.
DHCPv6 peut fournir a un equipement des adresses attribuees par un
serveur DHCPv6 ainsi que d'autres informations de configuration; ces
donnees sont transportees dans des options. DHCPv6 peut etre etendu
par la definition de nouvelles options pour transporter des
informations de configuration non specifiees dans ce document.
DHCPv6 prend egalement en charge un mecanisme de delegation
automatisee de prefixes IPv6. Grace a ce mecanisme, un serveur peut
deleguer des prefixes a des clients. L'utilisation de ce mecanisme
est specifiee dans le cadre de [RFC7084] et par [TR-187]. Noter que
ces documents utilisent "requesting router" et "delegating router" la
ou ce document utilise respectivement "client" et "server".
DHCP peut aussi etre utilise uniquement pour fournir d'autres options
de configuration (c.-a-d., sans adresses ni prefixes). Cela implique
que le serveur n'a pas a suivre d'etat; ce mode est donc appele
"stateless DHCPv6". Les mecanismes necessaires pour prendre en
charge stateless DHCPv6 sont beaucoup plus simples que ceux requis
pour prendre en charge stateful DHCPv6.
1.1. Relation avec les normes DHCPv6 precedentes
[RFC8415] fournissait une definition unifiee, corrigee et nettoyee de
DHCPv6 qui couvrait aussi tous les errata applicables deposes contre
les RFC plus anciennes au moment de sa redaction. Il a egalement
rendu obsoletes un petit nombre de mecanismes: l'authentification
differee, lifetime et les indications de temporisation envoyees par un
client.
Ce document rend [RFC8415] obsolete. Il applique des rapports
d'errata verifies et rend obsoletes deux fonctionnalites qui n'ont pas
ete largement implementees - l'attribution d'adresses temporaires au
moyen de l'option IA_TA et l'autorisation pour les clients d'envoyer
certains messages directement au serveur en unicast si le serveur a
envoye l'option Server Unicast a un client dans un echange initial.
Il clarifie egalement les ports UDP utilises par les clients, les
serveurs et les agents relais (Section 7.2). Voir Appendix A pour la
liste des differences par rapport a [RFC8415].
1.2. Sujets hors perimetre
Ce document specifie le comportement de DHCPv6. La politique du
serveur, par exemple quelles options attribuer a quels clients, quels
sous-reseaux ou pools de ressources utiliser, quelles requetes de
clients doivent etre refusees, etc., sort du perimetre de ce document.
La configuration, l'exploitation et la gestion des serveurs sortent
egalement du perimetre. Une approche de gestion des relais et
serveurs DHCPv6 est specifiee dans [RFC9243].
La fusion de la configuration DHCPv4 [RFC2131] et DHCPv6 sort du
perimetre de ce document. [RFC4477] examine certains problemes et
strategies possibles pour exploiter ensemble les services DHCPv4 et
DHCPv6. Bien que [RFC4477] soit un peu ancien, il fournit une bonne
vue d'ensemble des problemes en cause. Le consensus de l'IETF au
moment de la redaction est que DHCPv4 devrait etre utilise plutot que
DHCPv6 pour transmettre des informations de configuration IPv4 aux
noeuds. Pour les reseaux IPv6-only, [RFC7341] decrit un mecanisme de
transport permettant de transporter des messages DHCPv4 au moyen de
DHCPv6 pour le provisionnement dynamique de l'adresse IPv4 et des
informations de configuration.