Groupe de travail Réseau	E. Gray, Ericsson	
Request for Comments : 4548	J. Rutemiller, Ericsson	
RFC mises à jour : 1888, 4048 	G. Swallow, Cisco Systems, Inc.	
Catégorie : Sur la voie de la normalisation	mai 2006	
	Traduction Claude Brière de L'Isle	

Allocation de codets Internet (ICP) pour adresses NSAP

Statut du présent mémoire
Le présent document spécifie un protocole de l’Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Protocoles officiels de l’Internet" (STD 1) pour voir l’état de normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Notice de Copyright
Copyright (C) The Internet Society (2006).

Résumé
Le présent document est destiné à accomplir deux tâches en relations très étroites : établir une allocation "initiale" de codets Internet (ICP, Internet Code Point) pour chaque codage d'adresse IPv4 et IPv6 dans les adresses de point d'accès de service réseau (NSAP, Network Service Access Point) et recommander une politique d'allocation de la part de l'IANA pour les valeurs d'ICP non actuellement allouées. Dans la première tâche, le présent document remplace partiellement la RFC1888 – en particulier sa Section 6. Dans la seconde tâche, le présent document incorpore les termes et les spécifications de la Recommandation UIT-T X.213 et recommande de plus que l'IANA utilise la politique de "consensus de l'IETF" pour faire les futures allocations d'ICP.
Table des matières
1. Introduction	1
1.1 Conventions	2
1.2 Acronymes et terminologie	2
2. Considérations relatives à l'IANA	2
3. Allocations initiales et utilisations	3
3.1 Codage des adresses IPv4 dans une NSAPA	3
3.2 Codage des adresses IPv6 dans une NSAPA	3
4. Considérations sur la sécurité	4
5. Références	4
5.1 Références normatives	4
5.2 Références pour information	5
Adresse des auteurs	5
Déclaration complète de droits de reproduction	5

 	1.	Introduction

La Section 6 de la [RFC1888] fournissait précédemment l'allocation de la valeur initiale de codet Internet (ICP) "0" pour coder une adresse IPv6 dans une adresse de point d'accès (ou de rattachement) de service réseau [NSAP]. La RFC1888 définissait aussi plusieurs moyens pour restreindre le codage d'une adresse NSAP dans une adresse IPv6.

Les moyens par lesquels la RFC 1888 définissait le codage des adresses NSAP dans le format d'adresse IPv6 étaient lourdement annotés avec des avertissements et limitations à appliquer si ce codage était utilisé. Peut-être par suite de cela, ces codages n'ont pas été utilisés et ne paraissent jamais avoir été utilisés dans un déploiement de IPv6. De plus, la Section  6 contient des erreurs mineures. Par suite de ces diverses considérations, la [RFC1888] a été rendue obsolète et déclarée Historique par la [RFC4048].

Les auteurs du présent document pensent que les erreurs de la Section 6 de la RFC 1888 ont eu ce résultat – au moins en partie – parce que la Recommandation UIT-T [X.213] qui a l'origine allouait l'identifiant d'autorité et de format (AFI, Authority and Format Identifier) "35" à l'IANA n'a pas été librement publiée, ni n'a été incorporée ou expliquée en utilisant le mécanisme habituel de l'IETF, c'est-à-dire, une RFC.

L'objet du présent document est en partie de fournir cette explication.

De plus, parce que d'autres documents se réfèrent à l'allocation d'ICP IPv6 de la RFC 1888, il est nécessaire que les erreurs de la Section 6 de la RFC 1888 soient corrigées, sans considération du statut ultime de cette RFC.

Finalement, aucune RPC précédente (incluant la RFC 1888) n'a jamais formalisé une allocation d'un ICP IPv4. Ce peut être en partie à cause du manque de définition formelle de la politique d'allocation de l'IANA pour les valeurs d'ICP sous l'AFI alloué à l'IANA ("35").

Le présent document remplace la Section 6 de la RFC 1888 en définissant l'ICP pour le codage d'adresse IPv6 dans une adresse NSAP, et il formalise l'allocation d'ICP pour un codage d'adresse IPv4 dans une adresse NSAP.

 	1.1	Conventions
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	Acronymes et terminologie
AFI (Authority and Format Identifier)  : identifiant d'autorité et de format
BCD (Binary Coded Decimal)  : décimal codé en binaire
DSP (Domain Specific Part)  : partie spécifique de domaine
IANA (Internet Assigned Numbers Authority)  : autorité d'allocation des numéros de l'Internet
ICP (Internet Code Point)  : codet Internet
IDI (Initial Domain Identifier)  : identifiant de domaine initial
IDP (Initial Domain Part)  : partie de domaine initial
IETF (Internet Engineering Task Force)  : équipe d'ingénierie de l'Internet
ISO (International Organization for Standardization)  : organisation internationale de normalisation
NSAP (Network Service Access (or Attachment) Point)  : point d'accès (ou de rattachement) de service réseau
NSAPA  : adresse NSAP ; format d'adresse sur 20 octets
OSI (Open Systems Interconnection)  : interconnexion des systèmes ouverts
RFC (Request For Comments)  : demande de commentaires

 	2.	Considérations relatives à l'IANA

La Recommandation UIT-T [X.213] a alloué deux AFI désignant l'IANA comme autorité d'allocation. Un de ces deux AFI ("34") est destiné à l'allocation des NSAPA en format numérique décimal. Le présent document ne traite pas de l'allocation de cet AFI car il n'est pas clair pour le moment qu'une utilisation puisse être faite de ce format de codage. L'autre AFI ("35") est à utiliser pour le codage binaire sauf comme noté ci-dessous.

Le format de NSAPA consiste en une partie de domaine initial (IDP, Initial Domain Part) et une partie spécifique du domaine (DSP, Domain Specific Part). L'IDP, quant à lui, consiste en un identifiant d'autorité et de format (AFI, Authority and Format Identifier) et un identifiant de domaine initial (IDI, Initial Domain Identifier). L'AFI est défini comme étant un octet binaire, et l'IDI est défini comme étant un nombre de quatre chiffres décimaux codés sur deux octets en utilisant le format décimal codé en binaire (BCD, Binary Coded Decimal). Chaque morceau de l'IDI est utilisé pour représenter un chiffre décimal, en utilisant les valeurs binaire de "0000" à "1001".

En affectant l'autorité d'allocation pour l'AFI "35" à l'IANA, la Recommandation UIT-T [X.213] spécifie que l'IDI de deux octets sera utilisé pour contenir un codet Internet (ICP, Internet Code Point) qui, à cause du codage décimal, DOIT être dans la gamme décimale de "0" à "9999".

La Recommandation UIT-T suppose l'allocation de l'ICP "0" (zéro) pour le codage d'adresse IPv6 dans une adresse de point d'accès de service réseau (NSAPA, Network Service Access Point Address) (ou souvent NSAP). De plus, l'UIT-T supposait que l'IANA allouerait un ICP pour le codage d'adresse IPv4 dans une NSAPA et X.213 supposait que la valeur d'ICP à cette fin serait "1".

Dans une NSAPA, le DSP est constitué des octets restants après le IDP. Pour l'AFI "35", ce sont 17 octets d'un format défini par l'IANA ou défini par une autre partie et publié avec le consentement de l'IANA.

L'IANA, en tant qu'autorité responsable de l'AFI "35", NE DEVRAIT PAS allouer un ICP sans un format correspondant défini, et publié au moment de l'allocation du codet.

L'IANA a alloué les valeurs d'ICP suivantes :

Valeur d'ICP	Codage d'adresse	Définition du format
    "0"	Ipv6	RFC 4548, paragraphe 3.2
    "1"	Ipv4	RFC 4548, paragraphe 3.1

Les valeurs décimales restantes "2" à "9999" DOIVENT être allouées sur la base du consensus de l'IETF [RFC2434].

 	3.	Allocations initiales et utilisations

Le présent document continue la définition de l'allocation et du format d'ICP comme précédemment définie dans la RFC  1888, et formalise l'allocation de la valeur d'ICP "1" pour le codage et le format IPv4 à utiliser. Les paragraphes qui suivent décrivent les formats spécifiques d'IPv4 et d'IPv6 de codage d'adresse.

 	3.1	Codage des adresses IPv4 dans une NSAPA
Si il est exigé, pour une raison quelconque, d'incorporer une adresse IPv4 dans une adresse NSAP de 20 octets, le format suivant DOIT être utilisé. Note : l'alignement est un artefact de l'usage de NSAPA existant.

Une utilisation spécifique possible de cette incorporation est d'exprimer une adresse IP dans le format d'adresse de l'ATM Forum. Une autre utilisation possible serait de permettre que des paquets du protocole de réseau sans connexion (CLNP, Connectionless Network Protocol) qui encapsulent des paquets IPv4 soient acheminés dans un réseau CLNP en utilisant l'architecture d'adresse IPv4. Plusieurs octets de tête de l'adresse IPv4 pourraient être utilisés comme préfixe d'acheminement CLNP.

Une NSAPA avec une valeur d'AFI de "35" et une valeur d'ICP de "1" (un) code une adresse IPv4 de quatre octets dans les quatre premiers octets du DSP. Les 13 derniers octets du DSP sont non spécifiés dans le présent document. Pour garder la compatibilité avec le format NSAP et l'adressage IPv4, ces octets DOIVENT être présents, mais n'ont pas de signification intrinsèque pour IPv4. La valeur par défaut pour les octets non spécifiés est zéro.

       0                   1                   2                   3
       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 0-3  |  AFI = 0x35   |   ICP = 0001                  | IPv4 (octet 0)|
      +---------------+---------------+---------------+---------------+
 4-7  |             IPv4 (octets 1-3)                 |               |
      +---------------+---------------+---------------+---------------+
 8-11 |                                                               |
      +---------------+---------------+---------------+---------------+
 12-15|                                                               |
      +---------------+---------------+---------------+---------------+
 16-19|                                                               |
      +---------------+---------------+---------------+---------------+

Une NSAPA avec le code d'AFI de l'IANA et l'ICP réglé à "1" (un) est convertie en une adresse Ipv4 en supprimant les trois premiers et les treize derniers octets. Si le contenu adressé par NSAP est passé à une couche supérieure, les 13 derniers octets DEVRAIENT être présentés aussi à la couche supérieure.

Si une adresse NSAP qui utilise ce codage est utilisée pour l'acheminement dans une architecture d'acheminement IPv4, seule l'adresse IPv4 de quatre octets PEUT être prise en compte.

 	3.2	Codage des adresses IPv6 dans une NSAPA
Si il est exigé, pour une raison quelconque, d'incorporer une adresse IPv6 au sein d'une adresse NSAP de 20 octets, le format suivant DOIT alors être utilisé. Note :  l'alignement est un artefact de l'usage de NSAPA existant.

Une utilisation spécifique possible de cette incorporation est d'exprimer une adresse IP dans le format d'adresse de l'ATM Forum. Une autre utilisation possible serait de permettre que des paquets CLNP qui encapsulent les paquets IPv6 soient acheminés par un réseau CLNP en utilisant l'architecture d'adresse IPv6. Plusieurs octets de tête de l'adresse IPv6 pourraient être utilisés comme préfixe d'acheminement CLNP.

Une NSAPA avec une valeur d'AFI de "35" et une valeur d'ICP de "0" (zéro) code une adresse IPv6 de seize octets dans les seize premiers octets du DSP. Le dernier octet du DSP est un sélecteur. Pour garder la compatibilité avec le format NSAP et l'adressage IPv6, cet octet DOIT être présent, mais n'a pas de signification intrinsèque pour IPv6. Sa valeur par défaut est zéro, mais d'autres valeurs peuvent être utilisées comme spécifié pour toute application spécifique. Par exemple, cet octet peut être utilisé pour spécifier un des 255 numéros d'accès possibles.

       0                   1                   2                   3
       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 0-3  |  AFI = 0x35   |   ICP = 0000                  | IPv6 (octet 0)|
      +---------------+---------------+---------------+---------------+
 4-7  |             IPv6 (octets 1-4)                                 |
      +---------------+---------------+---------------+---------------+
 8-11 |             IPv6 (octets 5-8)                                 |
      +---------------+---------------+---------------+---------------+
 12-15|             IPv6 (octets 9-12)                                |
      +---------------+---------------+---------------+---------------+
 16-19|       IPv6 (octets 13-15)                     |               |
      +---------------+---------------+---------------+---------------+

Une NSAPA avec le code d'AFI de l'IANA et l'ICP réglé à "0" (zéro) est convertie en une adresse IPv6 en supprimant les trois premiers octets et le 20ème octet. Si le contenu adressé par NSAP est passé à une couche supérieure, le dernier octet DEVRAIT être présenté aussi à la couche supérieure.

Si une adresse NSAP qui utilise ce codage est utilisée pour l'acheminement dans une architecture d'acheminement IPv6, seule l'adresse IPv6 de 16 octets PEUT être prise en compte.

 	4.	Considérations sur la sécurité

Le codage NSAP des adresses IPv4 et IPv6 est compatible avec les mécanismes de sécurité correspondants de la [RFC4301], donc le présent document n'introduit pas de nouvelle exposition de la sécurité de l'Internet.

 	5.	Références
 	5.1	Références normatives

[NSAP]	Norme ISO/CEI 8348:2002, "Technologie de l'information - Interconnexion des systèmes ouverts – Définition du service réseau", 2002.

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

[RFC2434]	T. Narten et H. Alvestrand, "Lignes directrices pour la rédaction d'une section Considérations relatives à l'IANA dans les RFC", BCP 26, octobre 1998. (Rendue obsolète par la RFC5226)

[RFC4301]	S. Kent et K. Seo, "Architecture de sécurité pour le protocole Internet", décembre 2005. (P.S.) (Remplace la RFC2401)

[X.213]	Recommandation UIT-T X.213, "Réseaux de données et communications dans les systèmes ouverts", octobre 2001.

 	5.2	Références pour information

[RFC1888]	J. Bound, B. Carpenter, D. Harrington, J. Houldsworth, A. Lloyd, "NSAP OSI et IPv6", août 1996. (Obsolète, voir RFC4048) (MàJ par RFC4548) (Historique)

[RFC4048]	B. Carpenter, "La RFC 1888 est obsolète", avril 2005. (MàJ par RFC4548) (Info.)

 	Adresse des auteurs
Eric Gray	John Rutemiller	George Swallow	
Ericsson	Ericsson	Cisco Systems, Inc.	
900 Chelmsford Street	3000 Marconi Drive	1414 Massachusetts Avenue	
Lowell, MA, 01851	Warrendale, PA, 15086-7502	Boxborough, MA, 01719	
mél : Eric.Gray@Marconi.com 	mél : John.Rutemiller@Marconi.com 	mél : swallow@cisco.com 	

 	Déclaration complète de droits de reproduction

Copyright (C) The IETF Trust (2006).

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

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

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

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

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

Remerciement 
Le financement de la fonction d’édition des RFC est fourni par l'activité de soutien administatif (IASA) de l'IETF.