Équipe d'ingénierie de l'Internet (IETF)	G. Bajko, Nokia	
Request for Comments: 5678	S. Das, Telcordia Technologies Inc.	
Catégorie : Sur la voie de la normalisation	décembre 2009	
ISSN: 2070-1721	Traduction Claude Brière de L'Isle	

Options du protocole de configuration dynamique d'hôte (DHCPv4/v6) pour services de mobilité (MoS) IEEE 802.21

Résumé
Le présent document définit de nouvelles options du protocole de configuration dynamique d'hôte (DHCP, Dynamic Host Configuration Protocol (DHCPv4 et DHCPv6)) qui contiennent une liste des adresses IP et une liste de noms de domaines qui peuvent être transposées aux serveurs qui fournissent le type IEEE 802.21 de services de mobilité (MoS) (voir la RFC 5677). Ces services de mobilité sont utilisés pour aider un nœud mobile (MN) à la préparation d'un transfert inter cellulaire (découverte de réseau) et à la décision de transfert inter-cellulaire (choix de réseau). Les services visés dans ce document sont les services de transfert inter-cellulaire indépendants du support définis dans IEEE 802.21.

Statut de ce mémoire
Ceci est un document de l’Internet sur la voie de la normalisation.

Le présent document a été produit par l’équipe d’ingénierie de l’Internet (IETF). Il représente le consensus de la communauté de l’IETF. Il a subi une révision publique et sa publication a été approuvée par le groupe de pilotage de l’ingénierie de l’Internet (IESG). Tous les documents approuvés par l’IESG ne sont pas candidats à devenir une norme de l’Internet ; voir la Section 2 de la RFC5741.

Les informations sur le statut actuel du présent document, tout errata, et comment fournir des réactions sur lui peuvent être obtenues à http://www.rfc-editor.org/info/rfc5678 

Notice de droits de reproduction
Copyright (c) 2009 IETF Trust et les personnes identifiées comme auteurs du document. Tous droits réservés.

Le présent document est soumis au BCP 78 et aux dispositions légales de l’IETF Trust qui se rapportent aux documents de l’IETF (http://trustee.ietf.org/license-info) en vigueur à la date de publication de ce document. Prière de revoir ces documents avec attention, car ils décrivent vos droits et obligations par rapport à ce document. Les composants de code extraits du présent document doivent inclure le texte de licence simplifié de BSD comme décrit au paragraphe 4.e des dispositions légales du Trust et sont fournis sans garantie comme décrit dans la licence de BSD simplifiée.

Table des matières
1. Introduction	2
1.1 Conventions utilisées dans ce document	2
1.2 Terminologie	2
2. Option Adresse IPv4 de MoS pour DHCPv4	2
3. Option Liste de noms de domaine de MoS pour DHCPv4	4
4. Option Adresse IPv6 de MoS pour DHCPv6	5
5. OPtion Liste de noms de domaine de MoS pour DHCPv6	5
6. Usage des options	6
6.1 Usage des options de MoS pour DHCPv4	6
6.2 Usage des options de MoS pour DHCPv6	7
7. Considérations sur la sécurité	7
8. Considérations relatives à l'IANA	8
9. Remerciements	8
10. Références	8
10.1 Références normatives	8
10.2 Références pour information	9
Adresse des auteurs	9

 	1.	Introduction

[IEEE802.21] définit trois types de service distincts pour faciliter les transferts inter cellulaires de couche de liaison à travers des technologies hétérogènes :

a)	Services d'information (IS, Information Services) : les IS fournissent un cadre unifié aux entités de couche supérieure à travers un environnement de réseau hétérogène pour faciliter la découverte et le choix de plusieurs types de réseaux existants au sein d'une aire géographique. L'objectif est d'aider les protocoles de mobilité de couche supérieure à acquérir une vue globale des réseaux hétérogènes et d'effectuer un transfert inter cellulaire sans à-coups à travers ces réseaux.

b)	Services d'événement (ES, Event Services) : les événements peuvent indiquer des changements dans l'état et le comportement de transmission des couches physique, de liaison des données, et de liaison logique, ou prédire des changements d'état de ces couches. Le service d'événement peut aussi être utilisé pour indiquer des actions de gestion ou d'état de commande sur la partie de réseau ou sur une entité de gestion.

c)	Services de commande (CS, Command Services) : le service de commande permet aux couches supérieures de contrôler les couches physique, de liaison des données, et de liaison logique. Les couches supérieures peuvent contrôler la reconfiguration ou le choix d'une liaison appropriée à travers un ensemble de commandes de transfert inter cellulaire.

Dans la terminologie de l'IEEE, ces services sont appelés des services de transfert inter cellulaire indépendant du support (MIH, Media Independent Handover). Bien que ces services puissent être co-localisés, les différents schémas et types d'informations qu'ils fournissent ne nécessitent pas la co-localisation.

Un nœud mobile (MN) peut utiliser tous ces types de service MIH séparément ou dans toutes leurs combinaisons [RFC5677]. En pratique, un serveur de mobilité peut ne pas nécessairement héberger ces trois services MIH ensemble ; donc, il faut découvrir les types de service MIH séparément.

Le présent document définit de nouvelles options et sous-options DHCPv4 et DHCPv6 appelées Adresse IP de MoS et Liste des noms de domaine, qui permettent au MN de localiser un serveur de mobilité qui héberge le type de service désiré (c'est-à-dire, IS, ES, ou CS) comme défini dans [IEEE802.21]. À part la configuration manuelle, c'est une des solutions possibles pour localiser un serveur qui fournit des services de mobilité.

 	1.1	Conventions utilisées dans ce document
Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" en majuscules dans ce document sont à interpréter comme décrit dans le BCP 14, [RFC2119].

 	1.2	Terminologie
Services de mobilité : ensemble de services fournis par le réseau aux nœuds mobiles pour faciliter la préparation et la décision de transfert inter cellulaire. Dans le présent document, services de mobilité se réfère aux services définis dans les spécifications [IEEE802.21]

Serveur de mobilité : nœud de réseau qui fournit des services de mobilité.

Transfert inter cellulaire indépendant du support (MIH, Media Independent Handover) : comme défini dans [IEEE802.21].

Service MIH : type de service IS, ES, ou CS, comme défini dans [IEEE802.21].

 	2.	Option Adresse IPv4 de MoS pour DHCPv4
Cette section décrit IPv4 pour DHCPv4. La réception par le MN d'une adresse de MoS du réseau local ou du réseau de rattachement va dépendre du déploiement réel de réseau [RFC5677]. L'option Adresse IPv4 de MoS commence par un code d'option suivi par un champ Longueur et des sous-options. La valeur de l'octet de longueur n'inclut pas sa longueur ni celle du code d'option. La disposition de l'option est montrée ci-dessous :

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                | Code d'option |    Longueur   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------+---------------+
|                     Sous-option 1                             |
.                                                               .
+---------------+---------------+---------------+---------------+
|                       ...                                     |
.                                                               .
+---------------+---------------+---------------+---------------+
|                     Sous-option n                             |
.                                                               .
+---------------+---------------+---------------+---------------+

Code d'option : OPTION-IPv4_Address-MoS (139) - 1 octet.

Longueur : champ de 8 bits qui indique la longueur de l'option en excluant les champs "Code d'option" et "Longueur".

Sous-options : série de sous-options DHCPv4.

Quand la longueur totale d'une option Adresse IPv4 de MoS excède 254 octets, la procédure mentionnée dans la [RFC3396] DOIT être employée pour partager l'option en plusieurs options plus petites.

Une sous-option commence par un code de sous-option suivi par un champ Longueur et une ou plusieurs adresses IPv4. La disposition de la sous-option est montrée ci-dessous :

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Code ss-option |    Longueur   |    Adresse IP . . . . .
+---------------+---------------+---------------+---------------+
.                                                               .
.                                                               |
+---------------+---------------+---------------+---------------+

Les codes de sous-option sont résumés ci-dessous.

Code de sous option	Nom du service
1	IS
2	CS
3	ES

Si la longueur est suivie d'une liste d'adresses IPv4 indiquant les serveurs MIH appropriés disponibles au MN pour une option demandée, les serveurs DOIVENT être mentionnés dans l'ordre de préférence et le client devrait les traiter dans l'ordre de préférence décroissante. Dans le cas où il n'y a pas de serveur MIH disponible, la longueur est réglée à 0 ; autrement, c'est un multiple de 4.

La sous-option a le format suivant :

Lg de code  Adresse IPv4 1    Adresse IPv4 2
+-----+---+---+----+----+----+----+----+---
|1..3 | n |a1 | a2 |a3  | a4 | a1 |  ...
+-----+---+---+----+----+----+----+----+--

 	3.	Option Liste de noms de domaine de MoS pour DHCPv4

Cette section décrit l'option Liste de noms de domaines de MoS pour DHCPv4. Le format général de cette option est :

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                | Code d'option |   Longueur    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------+---------------+
|                     Sous-pption 1                             |
.                                                               .
+---------------+---------------+---------------+---------------+
|                       ...                                     |
.                                                               .
+---------------+---------------+---------------+---------------+
|                     Sous-pption n                             |
.                                                               .
+---------------+---------------+---------------+---------------+

Code d'option : OPTION-IPv4_FQDN-MoS (140) - 1 octet.

Longueur : champ de 8 bits qui indique la longueur de l'option en excluant les champs "Code d'option" et "Longueur".

Sous-options : série de sous-options DHCPv4.

Quand la longueur totale d'une option Liste de noms de domaines de MoS excède 254 octets, la procédure décrite dans la [RFC3396] DOIT être employée pour partager l'option en plusieurs options plus petites.

Une sous-option commence par un code de sous-option suivi par une longueur et un ou plusieurs noms de domaine pleinement qualifiés (FQDN, Fully Qualified Domain Name). La disposition de la sous-option est :

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code ss-option|    Longueur   |               FQDN  . . . . . .
+---------------+---------------+---------------+---------------+
.                                                               .
.                                                               |
+---------------+---------------+---------------+---------------+

Les codes de sous-option sont résumés ci-dessous.

Code de sous option	Nom du service
1	IS
2	CS
3	ES

Donc, la sous-option pour ce codage a le format suivant :

 Code  Long  Nom DNS du serveur de mobilité
+-----+----+----+-----+-----+-----+-----+--
|1..3 | n  | s1 |  s2 |  s3 |  s4 | s5  |  ...
+-----+----+----+-----+-----+-----+-----+--

La sous-option commence par un code de sous-option suivi par une longueur et une suite d'étiquettes qui sont codées conformément à la Section 8 de la [RFC3315].

La sous-option PEUT contenir plusieurs noms de domaines, mais ils devraient se référer aux enregistrements NAPTR des différents fournisseurs, plutôt qu'aux différents enregistrements A au sein du même fournisseur. C'est-à-dire, l'utilisation de plusieurs noms de domaines n'est pas destinée à remplacer les enregistrements NAPTR et SRV, mais plutôt à permettre à un seul serveur DHCP d'indiquer les serveurs MIH qui sont utilisés par plusieurs fournisseurs.

Le client DOIT essayer les enregistrements dans l'ordre mentionné, en appliquant le mécanisme décrit dans la [RFC5679] pour chacun. Le client résout seulement les noms de domaine suivants si les tentatives de contacter le premier ont échoué ou ne donnent pas de protocole de transport commun entre le MN et le serveur.

Par exemple, considérons le cas d'un serveur qui veut offrir deux serveurs IS MIH, "exemple.com" et "exemple.net". Cela va être codé comme suit :

+-----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|1..3 |26 | 7 |'e'|'x'|'e'|'m'|'p'|'l'|'e'| 3 |'c'|'o'|'m'| 0 |
+-----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 7 |'e'|'x'|'e'|'m'|'p'|'l'|'e'| 3 |'n'|'e'|'t'| 0 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+

 	4.	Option Adresse IPv6 de MoS pour DHCPv6

Cette section décrit l'option Adresse IPv6 de MoS pour DHCPv6. La réception par le MN d'une adresse de MoS provenant du réseau local ou du réseau de rattachement va dépendre du déploiement réel du réseau [RFC5677]. L'option de découverte de MoS commence par un code d'option suivi par une longueur et des sous-options. La valeur de l'octet de longueur n'inclut ni le champ Longueur ni le code d'option. La disposition de l'option est la suivante :

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Code d'option           |           Longueur            |
+---------------+---------------+---------------+---------------+
|                     Sous-option 1                             |
.                                                               .
+---------------+---------------+---------------+---------------+
|                       ...                                     |
.                                                               .
+---------------+---------------+---------------+---------------+
|                     Sous-option n                             |
.                                                               .
+---------------+---------------+---------------+---------------+

Code d'option : OPTION-IPv6_Address-MoS (54) - 2 octets

Longueur : champ de 16 bits qui indique la longueur de l'option en excluant les champs "Code d'option" et "Longueur".

Sous-options : série de sous-options DHCPv6.

Les sous-options suivent le même format (sauf la valeur du code de sous-option et de Longueur) que décrit à la Section 2. La valeur du code de sous-option et de Longueur fait 2 octets, et la longueur n'inclut ni elle-même ni le champ de code de sous-option. La disposition de la sous-option est la suivante :

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code de sous-option           |     Longueur                  |
+---------------+---------------+---------------+---------------+
|                   Adresse IP                                  |
.                                                               .
+---------------+---------------+---------------+---------------+

Les codes de sous-option sont résumés ci-dessous.

Code de sous option	Nom du service
1	IS
2	CS
3	ES

Si la longueur est suivie d'une liste d'adresses IPv6 indiquant des serveurs de MIH appropriés disponibles au MN pour une option demandée, les serveurs DOIVENT être mentionnés dans l'ordre de préférence et le client devrait les traiter dans l'ordre de préférence décroissante. Dans le cas où il n'y a pas de serveur MIH disponible, la longueur est réglée à 0 ; autrement, c'est un multiple de 16.

 	5.	Option Liste de noms de domaine de MoS pour DHCPv6

Cette section décrit l'option Liste de domaine MoS pour DHCPv6. Le format général de cette option est décrit ci-dessous.

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Code d'option           |          Longueur             |
+---------------+---------------+---------------+---------------+
|                     Sous-option 1                             |
.                                                               .
+---------------+---------------+---------------+---------------+
|                       ...                                     |
.                                                               .
+---------------+---------------+---------------+---------------+
|                     Sous-option n                             |
.                                                               .
+---------------+---------------+---------------+---------------+

Code d'option : OPTION-IPv6_FQDN-MoS (55) - 2 octets.

Longueur : champ de 16 bits qui indique la longueur de l'option en excluant les champs "Code d'option" et "Longueur".

Sous-options : série de sous options DHCPv6.

Les sous-options suivent le même format (sauf la valeur de code de sous-option et Longueur) que décrit à la Section 3. La valeur du code de sous-option et de Longueur fait 2 octets, et la Longueur n'inclut pas son propre champ ni le champ Code de sous option. La disposition de la sous-option est décrite ci-dessous :

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code de sous option           |     Longueur                  |
+---------------+---------------+---------------+---------------+
|                   FQDN                                        |
.                                                               .
+---------------+---------------+---------------+---------------+

Les codes de sous-option sont résumés ci-dessous.

Code de sous option	Nom du service
1	IS
2	CS
3	ES

La signification et le contenu du codage DHCPv6 de cette option sont exactement les mêmes que décrits à la Section 3, sauf la valeur de Code d'option et de Longueur.

 	6.	Usage des options
 	6.1	Usage des options de MoS pour DHCPv4
La demande et l'envoi des options DHCPv4 proposées suivent les règles des options DHCP dans la [RFC2131].

 	6.1.1	Comportement du nœud mobile
Le nœud mobile peut effectuer une découverte de MoS durant l'association initiale avec un réseau ou quand le service de mobilité est exigé. Il peut aussi essayer d'effectuer la découverte de MoS quand il manque des informations de réseau pour le MoS ou a besoin de changer le MoS pour des raisons quelconques, par exemple, pour récupérer du seul point de défaillance du MoS existant.

Afin de découvrir l'adresse IP ou le FQDN d'un MoS, le nœud mobile (client DHCP) DOIT inclure une option Adresse IPv4 de MoS ou une option Liste de noms de domaine de MoS dans la liste de demandes de paramètres (PRL, Parameter Request List) dans les messages DHCP respectifs, comme défini dans la [RFC2131].

Le client PEUT inclure une option Adresse IPv4 de MoS ou une option Liste de noms de domaine de MoS qui inclut une ou plusieurs sous-options avec le code de sous-option ou les codes qui représentent le ou les services qui intéressent le nœud mobile. Cependant, un client DEVRAIT être prêt à accepter une réponse provenant d'un serveur qui inclut d'autres sous-options ou n'inclut pas la ou les sous-options demandées.

 	6.1.2	Comportement du serveur DHCP
Quand le serveur DHCP reçoit une option Adresse IPv4 de MoS ou une option Liste de noms de domaine de MoS dans la PRL, le serveur DHCP DOIT inclure l'option dans son message de réponse comme défini dans la [RFC2131].

Un serveur PEUT utiliser des sous-options dans l'option Adresse IPv4 de MoS ou une option Liste de noms de domaine de MoS reçue du message du client pour restreindre sa réponse aux sous-options demandées par le client. Dans le cas où le serveur ne peut pas trouver de serveur de mobilité satisfaisant une sous-option demandée, le serveur DEVRAIT retourner l'option MoS avec cette sous-option et la longueur de la sous-option réglée à 0.

 	6.2	Usage des options de MoS pour DHCPv6
La demande et l'envoi des options DHCPv6 proposées suivent les règles des options DHCP dans la [RFC3315].

 	6.2.1	Comportement du nœud mobile
Le nœud mobile peut effectuer la découverte de MoS soit durant l'association initiale avec un réseau, soit quand le service de mobilité est exigé. Il peut aussi essayer d'effectuer la découverte de MoS quand il manque des informations de réseau pour le MoS ou a besoin de changer le MoS pour une raison quelconque, par exemple, pour récupérer d'un seul point de défaillance du MoS existant.

Afin de découvrir l'adresse IP ou le FQDN d'un MoS, le nœud mobile (client DHCP) DOIT inclure une option Adresse IPv6 de MoS ou une option Liste de noms de domaine de MoS dans l'option Demande d'option (ORO, Option Request Option) dans les messages DHCP respectifs, comme défini dans la [RFC3315].

Le client PEUT inclure une option Adresse IPv6 de MoS ou une option Liste de noms de domaines de MoS qui inclut une ou plusieurs sous-options avec le ou les codes de sous-option qui représentent le ou les services qui intéressent le nœud mobile. Cependant, un client DEVRAIT être prêt à accepter une réponse d'un serveur qui inclut d'autres sous-options ou n'inclut pas la ou les sous-options demandées.

 	6.2.2	Comportement du serveur DHCP
Quand le serveur DHCP reçoit une option Adresse IPv6 de MoS ou une option Liste de noms de domaines de MoS dans une ORO, le serveur DHCP DOIT inclure l'option dans son message de réponse comme défini dans la [RFC3315].

Un serveur PEUT utiliser des sous-options dans l'option Adresse IPv6 de MoS ou Liste de noms de domaines de MoS reçue du message du client pour restreindre sa réponse aux sous options demandées par le client. Dans le cas où le serveur ne peut pas trouver de serveur de mobilité satisfaisant une sous-option demandée, le serveur DEVRAIT retourner l'option MoS avec cette sous-option et la longueur de la sous-option réglée à 0.

 	7.	Considérations sur la sécurité

Les considérations sur la sécurité de la [RFC2131] s'appliquent. Si un adversaire s'arrange pour modifier la réponse d'un serveur DHCP ou insère sa propre réponse, un MN pourrait être conduit à contacter un serveur de mobilité félon, qui va éventuellement fournir de mauvaises informations, événements ou commandes pour le transfert inter cellulaire.

Il est recommandé d'utiliser les options d'authentification DHCP décrites dans la [RFC3118] lorsque elles sont disponibles. Cela va aussi protéger contre les attaques de déni de service sur les serveurs DHCP. La [RFC3118] fournit des mécanismes pour l'authentification d'entité et de message.

Dans les déploiements où l'authentification DHCP n'est pas disponible, les services de sécurité de couche inférieure peuvent être suffisant pour protéger les messages DHCP.

Concernant la résolution de nom de domaine, il est recommandé de considérer l'usage de DNSSEC [RFC4033] et les aspects des pratiques opérationnelles de DNSSEC [RFC4641]. Les considérations sur la sécurité décrites dans la [RFC5679] s'appliquent aussi.

 	8.	Considérations relatives à l'IANA

Le présent document définit deux nouvelles options DHCPv4 comme décrit dans les sections 2 et 3.

Option Adresse IPv4 de MoS pour DHCPv4 (OPTION-IPv4_Address-MoS) : 139

Option Liste de noms de domaines de MoS pour DHCPv4 (OPTION-IPv4_FQDN-MoS) : 140

Le présent document crée un nouveau registre pour les champs de sous-option dans les options Adresse DHCPv4 de MoS et FQDN, appelé "Type de service IEEE 802.21" (sections 2 et 3).

IS : 1
CS : 2
ES : 3

Les valeurs "0" et "255" sont réservées. Les  valeurs de "1" à "3" sont allouées comme ci-dessus, et le reste est disponible. Les nouvelles valeurs peuvent être allouées via action de normalisation, comme défini dans la [RFC5226].

Le présent document définit aussi deux options DHCPv6 comme décrit dans les sections 4 et 5.

Option Adresse IPv6 de MoS pour DHCPv6 (OPTION-IPv6_Address-MoS) : 54

Option Liste de noms de domaine de MoS pour DHCPv6 (OPTION-IPv6_FQDN-MoS) : 55

Le présent document crée un nouveau registre pour le champ Sous-option dans les options Adresse DHCPv6 de MoS et FQDN, appelé "Type de service IPv6 IEEE 802.21" (sections 4 et 5).

IS : 1
CS : 2
ES : 3

Les valeurs "0" et "65535" sont réservées. Les valeurs "1" à "3" sont allouées comme ci-dessus, et le reste est disponible. De nouvelles valeurs peuvent être allouées via une action de normalisation, comme défini dans la [RFC5226].

 	9.	Remerciements

Les auteurs tiennent à remercier les personnes suivantes de leurs précieux commentaires : Alfred Hoenes, Bernie Volz, David W. Hankins, Jari Arkko, Telemaco Melia, Ralph Droms, Ted Lemon, Vijay Devarapalli, et Yoshihiro Ohba.

 	10.	Références
 	10.1	Références normatives

[RFC2119]	S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997. DOI 10.17487/RFC2119, (MàJ par RFC8174)

[RFC2131]	R. Droms, "Protocole de configuration dynamique d'hôte", mars 1997. (DS) (Mà J par RFC3396, RFC4361, RFC5494, et RFC6849)

[RFC3118]	R. Droms et W. Arbaugh, "Authentification des messages DHCP", juin 2001. (P.S.) 

[RFC3315]	R. Droms, J. Bound, B. Volz, T. Lemon, C. Perkins et M. Carney, "Protocole de configuration dynamique d'hôte pour IPv6 (DHCPv6)", juillet 2003. (MàJ par RFC6422 et RFC6644, RFC7227 ; rendue obsolète par RFC8415)

[RFC3396]	T. Lemon et S. Cheshire, "Codage d'options longues dans le protocole de configuration dynamique d'hôte (DHCPv4)", novembre 2002.

[RFC4033]	R. Arends, et autres, "Introduction et exigences pour la sécurité du DNS", mars 2005, DOI 10.17487/RFC4033

[RFC5226]	T. Narten et H. Alvestrand, "Lignes directrices pour la rédaction d'une section Considérations relatives à l'IANA dans les RFC", BCP 26, mai 2008. (Remplace RFC2434 ; remplacée par RFC8126) 

[RFC5677]	T. Melia, éd., G. Bajko, S. Das, N. Golmie, JC. Zuniga, "Conception du cadre des services de mobilité IEEE 802.21 (MSFD)", décembre 2009. (P. S.)

[RFC5679]	G. Bajko, "Localisation des services de mobilité IEEE 802.21 avec le DNS" décembre 2009. (P. S.)

 	10.2	Références pour information

[RFC4641]	O. Kolkman, R. Gieben, "Fonctionnement pratique de DNSSEC", septembre 2006. (Remplace RFC2541) (Information)

[IEEE80221] "IEEE Standard for Local and Metropolitan Area Networks - Part 21: Media Independent Handover Services", IEEE LAN/MAN Std 802.21-2008, janvier 2009. http://www.ieee802.org/21/private/Published%20Spec/802.21-2008.pdf (l'accès au document est réservé aux membres).

 	Adresse des auteurs

Gabor Bajko	Subir Das	
Nokia	Telcordia Technologies Inc.	
mél : gabor.bajko@nokia.com	mél : subir@research.telcordia.com