Network Working Group E

Le présent document spécifie un protocole Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et des suggestions pour son amélioration. Prière de se reporter à l’édition actuelle du STD 1 "Normes des protocoles officiels de l’Internet" pour connaître l’état de normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Le présent document définit l’utilisation de la seconde version du protocole de localisation de service (SLPv2, localisation de service Protocol Version 2) sur les réseaux IPv6. Comme ce protocole s’appuie sur UDP et TCP, les changements pour sa prise en charge sur IPv6 sont mineurs.

Le présent document ne décrit pas comment utiliser SLPv1 sur les réseaux IPv6. Il n’y a au moment de sa publication aucune mise en œuvre ou déploiement de SLPv1 sur IPv6. Il est RECOMMANDÉ que SLPv2 soit utilisé en général, et en particulier sur les réseaux qui prennent en charge IPv6.

Table des Matières

1. Introduction 1

2. Élimination de la prise en charge des demandes SLP en diffusion 2

3. Spécification d’adresse pour les adresses IPv6 dans les URL 2

4. Comportement de diffusion groupée et d’envoi individuel SLP sur IPv6 2

4.1 Identifiants de groupe de diffusion groupée SLPv2 pour IPv6 2

4.2 Règles de limitation de portée SLPv2 pour IPv6 3

5. Considérations relatives à l’IANA 6

6. Considérations sur la sécurité 6

Remerciements 7

Références 7

Le protocole de localisation de service (SLP) fournit un cadre adaptable pour la découverte et le choix de services réseau. Avec ce protocole, les ordinateurs qui utilisent des réseaux fondés sur IP n’ont plus besoin d’autant de configuration statique des services réseau pour les applications fondées sur le réseau. Ceci est particulièrement important lorsque les ordinateurs deviennent plus mobiles, et les utilisateurs moins tolérants ou moins capables de satisfaire aux demandes de l’administration du réseau

On présente ici les changements nécessaires pour faire fonctionner le protocole de localisation de service sur IPv6. Ces changements incluent :

- l’utilisation des adresses de diffusion groupée IPv6 et des portées d’adresses IPv6 ;

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].

La localisation de service sur IPv4 permet l’envoi en diffusion des messages de demande de localisation de service. IPv6 fait usage de la diffusion groupée en liaison locale à la place de la diffusion. La configuration seulement en diffusion pour SLP n’est par prise en charge sous IPv6. Si un agent d’utilisateur souhaite faire une demande de découverte des agents de répertoire ou faire une demande de plusieurs agents de service, l’agent d’utilisateur DOIT envoyer la demande en diffusion groupée à l’adresse de diffusion groupée appropriée.

Ce changement modifie les exigences décrites au paragraphe 6.1 (Utilisation des accès, UDP et diffusion groupée) du protocole de localisation de service [RFC2608].

Chaque fois que possible le nom DNS [RFC1034] du service devrait être utilisé plutôt que la représentation numérique décrite dans cette section.

La localisation de service permet l’utilisation du protocole sans les avantages du DNS. Cela est pertinent lorsque un groupe de systèmes est connecté pour construire un réseau sans aucune configuration antérieure de serveurs pour prendre en charge ce réseau. Lorsque la localisation de service est utilisée de cette manière, les adresses numériques DOIVENT être utilisées pour identifier la localisation des services.

Le format d’un URL "service:" est défini dans la [RFC2609]. Cet URL est un "URI absolu" comme défini dans la [RFC2396].

Une adresse IPv6 numérique, comme on peut en utiliser dans un URL "service:", est spécifiée comme dans la [RFC2732]. La représentation textuelle définie pour les adresses littérales IPv6 dans la [RFC2373] :

num-addr = ; La syntaxe d’adresse IPv6 représentée en texte est comme au 2.2 de la [RFC2732],

Voici une adresse limitée au site local, comme il pourrait en être utilisé dans un message SLP DAAdvert.

Voici une adresse limitée à la liaison locale, comme il pourrait en être utilisé par un SA pour annoncer son service sur un réseau IPv6 sans routeur ou service DNS.

Le paragraphe 4.1 décrit comment différentes adresses de diffusion groupée sont utilisées pour transmettre et recevoir des messages SLPv2 sur IPv6. Le paragraphe 4.2 définit les règles d’utilisation de ces adresses et couvre les questions générales d’adresses à portée limitée.

SLPv2 pour IPv4 ne spécifie qu’une seule adresse de diffusion groupée, relative à une gamme d’adresses à portée administrativement limitée [RFC2365]. La raison pour laquelle une seule adresse a été utilisée est qu’il y a seulement 256 allocations relatives qui sont disponibles à cette fin. D’un autre côté, IPv6 a des adresses à portée limitée et suffisamment d’espace pour une gamme d’allocations.

SLPv2 pour IPv6 utilise les allocations d’identifiants de groupe de diffusion groupée suivantes :

Ces identifiants de groupe sont combinés avec le préfixe de portée de la portée à laquelle le message en diffusion groupée est à envoyer.

L’identifiant de groupe SVRLOC est utilisé pour les messages suivants : messages de demande de type de service et de demande d’attribut.

L’identifiant de groupe SVRLOC-DA est utilisé pour les demandes de service de diffusion groupée pour le type de service "service:directory-agent". Aussi, les DA envoient des messages d’annonce de DA non sollicités à l’identifiant de groupe de diffusion groupée SVRLOC-DA.

Tous les autres messages de demande de service de diffusion groupée sont envoyés à l’identifiant de groupe de diffusion groupée de localisation de service approprié. Les SA se joignent aux groupes qui correspondent au type de service des services qu’ils annoncent. L’identifiant de groupe est déterminé en utilisant l’algorithme fourni dans SLPv1 [RFC2165]. La chaîne Type de service utilisée dans la SrvRqst est haché à une valeur de 0 à 1023. Cela détermine le décalage dans la gamme FF0X::1:1000 à 13FF.

Une valeur V de 32 bits non signée est initialisée à 0. Chaque octet de la valeur de la chaîne de type de service codée en UTF-8 [RFC2272] est considéré tout à tour. La valeur courante de V est multipliée par 33, puis la valeur de la chaîne courante d’octets est ajoutée. Chaque octet de la chaîne Type de service est traité de cette manière. Le résultat est contenu dans les dix bits de moindre poids de V. Par exemple, le code suivant met en œuvre cet algorithme :

IPv6 fournit des portées différentes pour la configuration d’adresse d’interface et les adresses de diffusion groupée. Un agent SLPv2 pourrait découvrir des services qu’il ne peut pas utiliser ou ne pas découvrir des services qu’il pourrait utiliser sauf si des règles sont données pour l’empêcher.

Disons, par exemple qu’un UA SLPv2 pourrait demander un service en utilisant une diffusion groupée de site local et obtenir un URL service: contenant une adresse littérale de liaison locale. Si le service référencé n’était pas sur la même liaison que l’UA SLPv2, le service ne pourrait pas être joint.

Un agent SLPv2 PEUT envoyer un message en diffusion groupée en utilisant toute portée qui lui est permise (voir au paragraphe 4.2.2). Un SA et un DA DOIVENT se joindre à tous les groupes auxquels un agent SLPv2 peut envoyer un message. Cela assure que le SA ou DA sera capable de recevoir tous les messages en diffusion groupée.

Précisément, un agent SLPv2 NE DOIT PAS se joindre à un groupe de diffusion groupée qui a une portée plus grande pour une interface que ce qu’il est configuré pour utiliser en envoi individuel. Par exemple, une interface qui n’est configurée qu’avec une adresse de liaison locale se joint à des groupes dans des portées de FF01 et FF02. Si l’interface est configurée avec une adresse de site local ou mondiale, la portée de tous les groupes de diffusion groupée auxquels elle se joint peut ne pas être plus grande que la portée FF05. Dans ce cas, les SA et DA SLPv2 DOIVENT se joindre à des groupes de diffusion groupée dans toutes les portées suivantes : FF01 à FF05.

Un DA DOIT se joindre au groupe SVRLOC-DA pour recevoir les messages SrvRqst qui demandent les DAAdvert.

Un SA DOIT se joindre aux groupes à partir de la gamme de localisation de service des identifiants de groupe pour recevoir les messages SrvRqst. Le SA ne se joint qu’aux groupes correspondant aux services qu’il annonce. Par exemple, un agent de service qui répond aux demandes pour "service:service-agent" (utilisé pour la découverte de SA) se joindrait aux groupes dont l’identifiant de groupe est déduit de la fonction de hachage définie au paragraphe 4.1 :

identifiant de groupe à joindre = slp_hash("service:service-agent") + adresse de base

Le SA PEUT se joindre au groupe SVRLOC afin de recevoir les messages SrvTypeRqst et AttrRqst ; ces caractéristiques sont de mise en œuvre FACULTATIVE pour le SA.

Un UA PEUT se joindre au groupe SVRLOC-DA à toute portée ou toutes ces portées afin de recevoir les messages DAAdvert.

La portée maximum pour un message SLPv2 en diffusion groupée est site local (FF05).

Les messages SLPv2 en diffusion groupée sont envoyés en utilisant un groupe particulier. Un agent SLPv2 DOIT produire cette demande en utilisant une adresse de source avec une portée non inférieure à la portée du groupe de diffusion groupée.

Cela empêche, par exemple, un message en diffusion groupée de site local d’être envoyé d’une adresse de source de liaison locale.

Un UA SLPv2 avec une interface configurée avec au moins une adresse mondiale pourrait envoyer en diffusion groupée une SrvRqst à toute portée jusqu’à et incluant site local, par exemple.

Les SA et DA SLPv2 DOIVENT déterminer dans quelle portée est une adresse d’URL service:. Cela peut être fait en examinant si l’URL contient une adresse IPv6 numérique. Si l’URL contient un nom d’hôte, le SA ou DA DOIT résoudre ce nom en un ensemble d’adresses.

Un SA ou DA SLPv2 NE DOIT PAS répondre à une SrvRqst par un URL service: pour un service avec une portée d’adresse inférieure à la portée de l’adresse de source de la demande. Les règles sont données à la Figure 1, ci-dessous.

Cela empêche les UA d’être capables de découvrir des URL service: pour des services qui ne peuvent pas être joints.

Une zone de portée, ou simplement une zone, est une région de topologie connectée d’une certaine portée. Par exemple, l’ensemble de liaisons connectées par des routeurs au sein d’un certain site, et les interfaces rattachées à ces liaisons, comprend une seule zone de portée site local. Pour comprendre la distinction entre portées et zones, on observe que les régions topologiques au sein de deux sites différents sont considérées comme étant deux zones DIFFÉRENTES, mais de MÊME portée.

Un hôte qui a plusieurs interfaces rattachées à différentes liaisons est par définition rattaché à deux zone de liaison locale. Un hôte peut aussi être rattaché à plusieurs zones d’autres portées.

Un agent SLPv2 NE DOIT PAS propager des annonces de service d’une zone à une autre. Une autre façon de dire cela est qu’un SA ou DA SLPv2 NE DOIT PAS répondre à une demande provenant d’une zone avec des informations de service associées à un service dans une zone différente.

L’implication spécifique de ces règles est discutée dans les paragraphes suivants.

Les localisations de service (dans les messages SrvReg, SrvRply, AttrRst, SAAdvert ou DAAdvert) dont la localisation est une adresse littérale DOIVENT être seulement envoyées aux agents SLP situés sur la même zone.

Par exemple, un URL service: qui contient une adresse de liaison locale sur la liaison A peut être envoyé dans un message SLPv2 sur la liaison A, seulement à une adresse de destination de liaison locale.

Chaque interface d’un appareil multi rattachements est potentiellement sur une liaison séparée. Il est souvent difficile de déterminer si deux interfaces sont connectées à la même liaison. Pour cette raison, une stratégie de mise en œuvre prudente est de ne pas produire de message SLP contenant de localisation de service de portée liaison locale sauf sur l’interface où on sait que le service réside.

Dans la Figure 2, l’UA est multi rattachements. L’UA peut produire une demande de service dans la Zone 1 et découvrir des services sur le SA ou dans la Zone 2 et découvrir des services annoncés par le DA. Par exemple, si la demande est produite à partir d’une adresse de source de liaison locale, le SA va seulement répondre avec un service disponible sur la liaison 1, le DA seulement avec un service disponible sur la liaison 2.

L’UA DOIT utiliser la découverte active pour détecter les DA avant de produire des demandes en diffusion groupée, conformément à la spécification SLPv2 [RFC2608]. L’UA DOIT produire des demandes en utilisant des portées de diffusion groupée croissantes, en commençant par FF01 et en augmentant jusqu’à la portée maximum de FF05, pour solliciter des annonces de DA. Noter les restrictions du paragraphe 4.2.2.

Si l’UA est incapable de découvrir de DA en utilisant la découverte en diffusion groupée, il peut produire des demandes en diffusion groupée de portée site local (FF05) ou moins. (Noter que l’adresse de source de la demande DOIT être au moins de la portée de la diffusion groupée, comme décrit au paragraphe 4.2.2.)

Si l’UA souhaite découvrir tous les services, il DOIT produire des demandes dans les deux zones 1 et 2.

Dans la Figure 3, le SA est multi rattachements. Le SA peut recevoir une demande de l’UA sur la Liaison 1 (Zone 1). Le SA NE DOIT PAS retourner des informations de service pour des services offerts sur une zone différente de la demande. Par exemple, l’UA pourrait découvrir des services offerts dans la Zone 1, mais pas dans la Zone 2.

Le SA peut recevoir une DAAdvert sur la Liaison 2 (Zone 2). Le SA NE DOIT PAS envoyer un enregistrement de service au DA pour un service qui est présent dans la Zone 1. Le SA DOIT enregistrer un service avec le DA présent dans la Zone 2.

Le SA NE DOIT PAS inclure un adresse dans un message SAAdvert qui est envoyé sur une zone où l’adresse n’est pas valide. Par exemple, le SA NE DOIT PAS envoyer de SAAdvert sur la liaison 2, si le SAADvert contient un URL service: avec une adresse littérale IPv6 de portée liaison locale pour Liaison 1.

Le SA effectue une découverte de DA active, comme décrit dans SLPv2 [RFC2608]. Le SA DOIT produire des demandes en utilisant la portée de diffusion groupée FF02 pour solliciter des annonces de DA. Si le SA a une adresse de source de site local ou mondiale, il DOIT produire à nouveau la demande avec des portées croissantes jusqu’à une portée maximum de FF05. La découverte de DA active DOIT être tentée dans les deux zones 1 et 2. Cela assure que le SA va découvrir autant de DA que possible dans sa portée.

Dans la Figure 4, le DA est multi rattachements. Le DA DOIT garder trace des enregistrements des interfaces. Le DA DOIT empêcher un enregistrement de SA qui contient des informations de service valides dans une zone d’être découvert dans une autre zone. Par exemple, les services enregistrés par le SA dans la Zone 2 ne devraient pas être découvrables par l’UA dans la Zone 1.

On DOIT faire attention lors de la production des annonces de DA. Le DA DOIT répondre aux demandes de découverte de DA actives en utilisant la même portée que la demande. Par exemple, si le SA produit un message SrvRqst pour le type de service "service:directory" à partir d’une adresse de source liaison locale, le DA DOIT répondre avec une adresse de source de liaison locale (liaison 2).

Le DA DOIT envoyer en diffusion groupée les annonces de DA non sollicitées sur chaque interface en utilisant des adresses de source de liaison locale et de site local, sauf si il est seulement configuré avec une adresse de liaison locale. Dans ce cas, le DA DOIT produire les annonces de DA avec seulement la portée liaison locale.

L’URL de DA DOIT contenir l’adresse de la plus grande portée à laquelle le DA est configuré dans la zone. Par exemple, si le DA est configuré avec une adresse de liaison locale, de site local, et mondiale, dans la Zone 2, il va utiliser l’adresse mondiale dans l’URL du DA (comme une adresse IPv6 littérale).

La gamme d’identifiants de groupe de diffusion groupée IPv6 de FF05::1:1000 à FF05::1:13FF a été précédemment allouée par l’IANA dans la RFC 2375 pour l’usage de SLP [RFC2375].

Le présent document définit comment la gamme des adresses FF0X::1:1000 à FF0X::1:13FF est utilisée. L’IANA a alloué cette gamme d’adresses à l’utilisation du protocole de localisation de service.

Le présent document définit pleinement les adresses de diffusion groupée que va utiliser ce protocole. Il n’y a pas d’exigence que l’IANA établisse un registre pour allouer des adresses supplémentaires.

Les agents d’utilisateur et les agents de répertoire PEUVENT ignorer tous les messages de localisation de service authentifiés lorsque il existe une association IPsec valide.

Les agents de service et les agents de répertoire DOIVENT être capables d’utiliser l’authentification IP et la charge utile de sécurité IP encapsulante pour produire et traiter les messages de localisation de service chaque fois qu’existe une association de sécurité IPsec appropriée [RFC2401].

SLP permet de produire des signatures numériques pour permettre la vérification du contenu des messages. Il n’y a rien dans le document des modifications pour IPv6 qui affaiblisse ou renforce cette technique.

Merci à Dan Harrington, Jim Wood et Alain Durand, Thomas Narten, Dave Thaler et Erik Nordmark pour leur relecture du présent document. John Veizades a contribué à la version d’origine de ce document. La fonction de hachage est modifiée à partir d’un fragment de code attribué à Chris Torek. Le texte sur les zones de portées est tiré d’un texte de Steve Deering, Brian Haberman et Brian Zill.

[RFC1035] P. Mockapetris, "Noms de domaines – Mise en œuvre et spécification", STD 13, novembre 1987. (MàJ par la RFC6604)

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

[RFC2272] J. Case, D. Harrington, R. Presuhn, B. Wijnen, "Traitement et distribution de message pour le protocole simple de gestion de réseau (SNMP)", janvier 1998. (Obsolète, voir RFC3412, STD 62) (P.S.)

[RFC2373] R. Hinden, S. Deering, "Architecture d'adressage IP version 6", juillet 1998. (Obsolète, voir RFC4291) (PS)

[RFC2732] R. Hinden, B. Carpenter et L. Masinter, "Format pour les adresses littérales IPv6 dans les URL", décembre 1999. (Obsolète, voir RFC3986, STD66) (P.S.)

Le présent document et ses traductions peuvent être copiés et fournis aux tiers, et les travaux dérivés qui les commentent ou les expliquent ou aident à leur mise en œuvre peuvent être préparés, copiés, publiés et distribués, en tout ou partie, sans restriction d’aucune sorte, pourvu que la déclaration de droits de reproduction ci-dessus et le présent paragraphe soient inclus dans toutes telles copies et travaux dérivés. Cependant, le présent document lui-même ne peut être modifié d’aucune façon, en particulier en retirant la notice de droits de reproduction ou les références à la Internet Society ou aux autres organisations Internet, excepté autant qu’il est nécessaire pour le besoin du développement des normes Internet, auquel cas les procédures de droits de reproduction définies dans les procédures des normes Internet doivent être suivies, ou pour les besoins de la traduction dans d’autres langues que l’anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Internet Society ou ses successeurs ou ayant droits.

Le présent document et les informations y contenues sont fournies 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 ci encloses ne violent aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

Le financement de la fonction d’édition des RFC est actuellement fourni par l’Internet Society.

Groupe de travail Réseau	E. Guttman
Request for Comments : 3111	Sun Microsystems
Catégorie : En cours de normalisation
Traduction Claude Brière de L’Isle	mai 2001