16. Validation des messages
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
16. Validation des messages
Cette section decrit quelles options sont valides dans quels types de
messages et explique ce qu'il faut faire lorsqu'un client ou un serveur
recoit un message contenant des options connues mais invalides pour ce
message. Par exemple, une IA option n'est pas autorisee dans un message
Information-request.
Les clients et les serveurs MAY choisir soit (1) d'extraire des
informations d'un tel message si ces informations sont utiles au
destinataire, soit (2) d'ignorer completement ce message et de le
rejeter.
Si un serveur recoit un message qu'il considere invalide, il MAY envoyer
un message Reply (ou Advertise, selon le cas) avec une Server Identifier
option (voir Section 21.3), une Client Identifier option (voir
Section 21.2) (si elle etait incluse dans le message), et une Status
Code option (voir Section 21.13) avec le statut UnspecFail.
Les clients, relay agents et serveurs MUST NOT rejeter les messages qui
contiennent des options inconnues (ou des instances d'options de
fournisseur avec des valeurs enterprise-number inconnues). Ces options
devraient etre ignorees comme si elles etaient absentes. Cela est
essentiel pour permettre les extensions futures de DHCP.
Un client ou un serveur MUST rejeter tout message DHCP recu avec un type
de message inconnu.
Les clients SHOULD NOT accepter les messages multicast.
Les serveurs SHOULD NOT accepter le trafic unicast provenant des
clients. La Server Unicast option (voir Section 21.12) et le code de
statut UseMulticast (voir Section 21.13) ont ete rendus obsoletes; par
consequent, les clients ne devraient plus envoyer de messages a
l'adresse unicast d'un serveur ni recevoir le code de statut
UseMulticast. Toutefois, un serveur qui prenait auparavant en charge la
Server Unicast option et qui est mis a niveau pour ne plus la prendre en
charge MAY continuer a recevoir des messages unicast s'il avait
precedemment envoye la Server Unicast option au client. Toutefois, cela
ne cause aucun dommage et le client finira par revenir a l'envoi de
messages multicast (par exemple apres que le temps de rebinding du bail
est atteint ou apres le redemarrage du client).
Les relay agents SHOULD NOT accepter les messages unicast provenant des
clients.
Note: Les regles multicast/unicast mentionnees ci-dessus s'appliquent
aux messages DHCP dans ce document. Les messages definis dans d'autres
documents ou dans des documents futurs peuvent avoir des regles
differentes.
16.1. Utilisation des Transaction IDs
Le champ "transaction-id" contient une valeur utilisee par les clients
et les serveurs pour correler les reponses du serveur aux messages du
client. Un client SHOULD generer un nombre aleatoire qui ne peut pas
etre facilement devine ou predit, afin de l'utiliser comme transaction
ID pour chaque nouveau message qu'il envoie. Noter que si un client
genere des identifiants de transaction facilement previsibles, il peut
devenir plus vulnerable a certains types d'attaques par des intrus hors
chemin. Un client MUST laisser le transaction ID inchange dans les
retransmissions d'un message.
16.2. Message Solicit
Les clients MUST rejeter tout message Solicit recu.
Les serveurs MUST rejeter tout message Solicit qui n'inclut pas de
Client Identifier option ou qui inclut une Server Identifier option.
16.3. Message Advertise
Les clients MUST rejeter tout message Advertise recu qui satisfait a
l'une des conditions suivantes:
* le message n'inclut pas de Server Identifier option (voir
Section 21.3).
* le message n'inclut pas de Client Identifier option (voir
Section 21.2).
* le contenu de la Client Identifier option ne correspond pas au DUID
du client.
* la valeur du champ "transaction-id" ne correspond pas a la valeur que
le client a utilisee dans son message Solicit.
Les serveurs et relay agents MUST rejeter tout message Advertise recu.
16.4. Message Request
Les clients MUST rejeter tout message Request recu.
Les serveurs MUST rejeter tout message Request recu qui satisfait a
l'une des conditions suivantes:
* le message n'inclut pas de Server Identifier option (voir
Section 21.3).
* le contenu de la Server Identifier option ne correspond pas au DUID
du serveur.
* le message n'inclut pas de Client Identifier option (voir
Section 21.2).
16.5. Message Confirm
Les clients MUST rejeter tout message Confirm recu.
Les serveurs MUST rejeter tout message Confirm recu qui n'inclut pas de
Client Identifier option (voir Section 21.2) ou qui inclut une Server
Identifier option (voir Section 21.3).
16.6. Message Renew
Les clients MUST rejeter tout message Renew recu.
Les serveurs MUST rejeter tout message Renew recu qui satisfait a l'une
des conditions suivantes:
* le message n'inclut pas de Server Identifier option (voir
Section 21.3).
* le contenu de la Server Identifier option ne correspond pas a
l'identifiant du serveur.
* le message n'inclut pas de Client Identifier option (voir
Section 21.2).
16.7. Message Rebind
Les clients MUST rejeter tout message Rebind recu.
Les serveurs MUST rejeter tout message Rebind recu qui n'inclut pas de
Client Identifier option (voir Section 21.2) ou qui inclut une Server
Identifier option (voir Section 21.3).
16.8. Message Decline
Les clients MUST rejeter tout message Decline recu.
Les serveurs MUST rejeter tout message Decline recu qui satisfait a
l'une des conditions suivantes:
* le message n'inclut pas de Server Identifier option (voir
Section 21.3).
* le contenu de la Server Identifier option ne correspond pas a
l'identifiant du serveur.
* le message n'inclut pas de Client Identifier option (voir
Section 21.2).
16.9. Message Release
Les clients MUST rejeter tout message Release recu.
Les serveurs MUST rejeter tout message Release recu qui satisfait a
l'une des conditions suivantes:
* le message n'inclut pas de Server Identifier option (voir
Section 21.3).
* le contenu de la Server Identifier option ne correspond pas a
l'identifiant du serveur.
* le message n'inclut pas de Client Identifier option (voir
Section 21.2).
16.10. Message Reply
Les clients MUST rejeter tout message Reply recu qui satisfait a l'une
des conditions suivantes:
* le message n'inclut pas de Server Identifier option (voir
Section 21.3).
* le champ "transaction-id" dans le message ne correspond pas a la
valeur utilisee dans le message original.
Si le client a inclus une Client Identifier option (voir Section 21.2)
dans le message original, le message Reply MUST inclure une Client
Identifier option, et le contenu de la Client Identifier option MUST
correspondre au DUID du client. Si le client n'a pas inclus de Client
Identifier option dans le message original, le message Reply MUST NOT
inclure de Client Identifier option.
Les serveurs et relay agents MUST rejeter tout message Reply recu.
16.11. Message Reconfigure
Les serveurs et relay agents MUST rejeter tout message Reconfigure recu.
Les clients MUST rejeter tout message Reconfigure qui satisfait a l'une
des conditions suivantes:
* le message n'a pas ete envoye en unicast au client.
* le message n'inclut pas de Server Identifier option (voir
Section 21.3).
* le message n'inclut pas de Client Identifier option (voir
Section 21.2) contenant le DUID du client.
* le message n'inclut pas de Reconfigure Message option (voir
Section 21.19).
* le msg-type de la Reconfigure Message option n'est pas une valeur
valide.
* le message n'inclut pas d'authentification (comme RKAP; voir
Section 20.4) ou echoue a la validation d'authentification.
16.12. Message Information-request
Les clients MUST rejeter tout message Information-request recu.
Les serveurs MUST rejeter tout message Information-request recu qui
satisfait a l'une des conditions suivantes:
* le message inclut une Server Identifier option (voir Section 21.3),
et le DUID dans l'option ne correspond pas au DUID du serveur.
* le message inclut une IA option.
16.13. Message Relay-forward
Les clients MUST rejeter tout message Relay-forward recu.
16.14. Message Relay-reply
Les clients et serveurs MUST rejeter tout message Relay-reply recu.