Ce chapitre contient des informations de référence concernant l'implémentation du protocole IPv6 sous Oracle Solaris 10.
Pour une présentation d'IPv6, reportez-vous au Chapitre 3Présentation d'IPv6. Les tâches de configuration d'un réseau compatible IPv6 sont décrites au Chapitre 7Configuration d'un réseau IPv6 (tâches).
Dans Solaris 10 7/07, le fichier /etc/inet/ipnodes devient obsolète. Comme expliqué dans chaque procédure, utilisez le chemin /etc/inet/ipnodes uniquement pour les versions précédentes de Oracle Solaris 10.
Le Chapitre 3Présentation d'IPv6 présente les formats d'adressage IPv6 les plus fréquents : adresse de site unicast et adresse locale de lien. Cette section apporte des informations complémentaires au Chapitre 3Présentation d'IPv6 et décrit en détail les formats d'adressage suivants :
Si vous envisagez de configurer un tunnel 6to4 à partir du point d'extrémité d'un routeur ou d'un hôte, vous devez publier le préfixe du site 6to4 dans le fichier /etc/inet/ndpd.conf stocké sur le système du point d'extrémité. Les tâches de configuration des tunnels 6to4 sont présentées à la section Procédure de configuration d'un tunnel 6to4.
L'illustration suivante présente les éléments d'un préfixe de site 6to4.
L'illustration suivante présente les éléments d'un préfixe de sous-réseau pour un site 6to4 tel qu'il serait inclus dans le fichier ndpd.conf.
Le tableau suivant explique les éléments constituant un préfixe de sous-réseau 6to4, les longueurs à respecter et leurs définitions.
Élément |
Longueur |
Définition |
---|---|---|
Préfixe |
16 bits |
Étiquette de préfixe 6to4 2002 (0x2002). |
Adresse IPv4 |
32 bits |
Adresse IPv4 unique déjà configurée sur l'interface 6to4. Pour la publication, vous devez spécifier la représentation hexadécimale de l'adresse IPv4 au lieu de celle au format décimal avec points. |
ID de sous-réseau |
16 bits |
ID de sous-réseau unique pour le lien du site 6to4. |
Lorsqu'un hôte IPv6 reçoit le préfixe 6to4 dérivé par le biais d'une publication de routeur, il reconfigure automatiquement une adresse 6to4 dérivée sur une interface. L'adresse possède le format suivant :
prefix:IPv4-address:subnet-ID:interface-ID/64 |
La commande ifconfig -a sur un hôte avec une interface 6to4 produit la sortie suivante :
qfe1:3: flags=2180841<UP,RUNNING,MULTICAST,ADDRCONF,ROUTER,IPv6> mtu 1500 index 7 inet6 2002:8192:56bb:9258:a00:20ff:fea9:4521/64 |
Dans cette sortie, l'adresse 6to4 dérivée vient à la suite de inet6.
Ce tableau décrit les éléments d'une adresse dérivée d'un préfixe 6to4, les longueurs à respecter et les informations qu'ils contiennent.
Élément de l'adresse |
Longueur |
Définition |
---|---|---|
prefix |
16 bits |
2002 (préfixe 6to4) |
adresse IPv4 |
32 bits |
8192:56bb (adresse IPv4 au format hexadécimal pour la pseudointerface 6to4 configurée sur le routeur 6to4) |
ID sous-réseau |
16 bits |
9258 (adresse du sous-réseau auquel l'hôte appartient) |
ID interface |
64 bits |
a00:20ff:fea9:4521 (ID de l'interface hôte configurée pour le site 6to4) |
L'adresse IPv6 multicast permet de distribuer des informations ou des services identiques à un groupe défini d'interfaces, appelé groupe multicast. En règle générale, les interfaces des groupes multicast appartiennent à des nœuds différents. Une interface peut faire partie d'un nombre indéfini de groupes multicast. Les paquets envoyés à l'adresse multicast sont distribués à tous les membres du groupe multicast. Par exemple, l'un des rôles des adresses multicast est de diffuser des informations de façon similaire à l'adresse de diffusion IPv4.
Le tableau suivant décrit le format d'une adresse multicast.
Tableau 11–1 Format d'adresse IPv6 multicast
8 bits |
4 bits |
4 bits |
8 bits |
8 bits |
64 bits |
32 bits |
11111111 |
FLGS |
SCOP |
Réservé |
Plen |
Préfixe réseau |
ID de groupe |
La liste suivante récapitule le contenu de chaque champ.
11111111 – Identifie l'adresse en tant qu'adresse multicast.
FLGS – Jeu des quatre indicateurs 0,0,P,T. Les deux premiers doivent être zéro. Le champ P possède l'une des valeurs suivantes :
0 = adresse multicast qui n'est pas assignée en fonction du préfixe réseau
1 = adresse multicast assignée en fonction du préfixe réseau
Si P est défini sur 1, T doit être défini sur 1.
Réservé - Valeur nulle réservée.
Plen - Nombre de bits au niveau du préfixe du site qui identifient le sous-réseau, pour une adresse multicast assignée en fonction du préfixe réseau.
ID de groupe - Identificateur du groupe multicast (permanent ou dynamique).
Pour des informations complètes sur le format multicast, reportez-vous au document RFC 3306, Unicast-Prefix-based IPv6 Multicast Addresses.
Certaines adresses IPv6 multicast sont assignées de façon permanente par l'IANA (Internet Assigned Numbers Authority). Par exemple, les adresses multicast de tous les nœuds et de tous les routeurs requises par tous les hôtes et routeurs IPv6. Les adresses IPv6 multicast peuvent également être assignées de façon dynamique. Pour plus d'informations sur l'utilisation appropriée des adresses et des groupes multicast, reportez-vous au document RFC 3307, Allocation Guidelines for IPv6 Multicast Addresses.
Le protocole IPv6 définit un jeu d'en-têtes comprenant l'en-tête IPv6 de base ainsi que les en-têtes d'extension IPv6. La figure suivante illustre les champs qui s'affichent dans l'en-tête IPv6 et l'ordre dans lequel ils apparaissent.
La liste suivante décrit la fonction de chaque champ d'en-tête.
Version – Numéro de version 4 bits du protocole Internet = 6.
Traffic class – Champ de classe de trafic 8 bits.
Flow label – Champ 20 bits.
Payload length – Entier sans signe 16 bits constituant le reste du paquet qui suit l'en-tête IPv6 (en octets).
Next header – Sélecteur 8 bits. Identifie le type d'en-tête qui suit immédiatement l'en-tête IPv6. Utilise la même valeur que le champ du protocole IPv4.
Hop limit – Entier sans signe 8 bits. Décrémentation de 1 par nœud transférant le paquet. Si la valeur du champ est définie sur zéro, le paquet est abandonné.
Source address – 128 bits. L'adresse du premier expéditeur du paquet.
Destination address – 128 bits. L'adresse du destinataire prévu du paquet. Le destinataire prévu n'est pas nécessairement le destinataire s'il existe un en-tête de routage facultatif.
Les options IPv6 sont placées dans des en-têtes d'extension distincts situés, dans un paquet, entre l'en-tête IPv6 et l'en-tête de la couche transport. La plupart des en-têtes d'extension IPv6 ne sont vérifiés ou traités par les routeurs qu'au moment où le paquet arrive à sa destination prévue. Cette fonction améliore de façon remarquable les performances du routeur pour les paquets qui contiennent des options. En effet, sous IPv4, toutes les options présentes dans un paquet doivent être vérifiées par le routeur.
À la différence des options IPv4, les en-têtes d'extension IPv6 possèdent une longueur indéfinie. De plus, le nombre d'options pouvant être incluses dans un paquet n'est pas limité à 40 octets. Grâce à cela et à la manière dont les options IPv6 sont généralement traitées, les options IPv6 peuvent servir à des fonctions difficiles d'utilisation dans IPv4.
Pour une meilleure gestion des en-têtes d'option suivants et du protocole de transport qui suit, les options IPv6 sont toujours des entiers avec une longueur multiple de 8 octets. Ce type d'entier permet de conserver l'alignement des en-têtes suivants.
Les en-têtes d'extension IPv6 ci-dessous sont actuellement définis :
Routing – Routage étendu tel que le routage IPv4 à la source lâche
Fragmentation – Fragmentation et réassemblage
Authentication – Intégrité, authentification et sécurité
Encapsulating Security Payload – Confidentialité
Hop-by-Hop options – Options spéciales requérant un traitement saut par saut
Destination options – Informations facultatives devant être vérifiées par le nœud de destination
Le terme double pile désigne la duplication complète de tous les niveaux de la pile de protocole des applications à la couche réseau. Par exemple, un système qui exécute à la fois les protocoles OSI et TCP/IP représente une duplication complète.
Oracle Solaris est de type double pile. En d'autres termes, Oracle Solaris implémente les protocoles IPv4 et IPv6. Lorsque vous installez ce système d'exploitation, vous pouvez choisir d'activer les protocoles IPv6 dans la couche IP ou d'utiliser les protocoles IPv4 définis par défaut. Le reste de la pile TCP/IP est identique. Par conséquent, les mêmes protocoles de transport, TCP UDP et SCTP, peuvent s'exécuter sur les réseaux IPv4 et IPv6. Les mêmes applications peuvent également s'exécuter sur ces réseaux. La Figure 11–4 illustre le fonctionnement des protocoles IPv4 et IPv6 sous forme de protocoles doubles piles à travers les différentes suites de protocoles Internet.
Dans un environnement à double pile, les sous-jeux des hôtes et des routeurs sont mis à niveau vers IPv4 et IPv6. Cette approche assure l'interopérabilité constante des nœuds mis à niveau avec des nœuds exclusivement IPv4.
Cette section décrit les fichiers, commandes et démons nécessaires au protocole IPv6 sous Oracle Solaris.
Cette section décrit les fichiers de configuration faisant partie de l'implémentation IPv6 :
Le fichier de configuration /etc/inet/ndpd.conf sert à configurer les options utilisées par le démon Neighbor Discovery in.ndpd. Pour un routeur, ndpd.conf sert principalement à configurer le préfixe du site à publier vers le lien. Pour un hôte, ndpd.conf sert à désactiver la configuration automatique des adresses ou à configurer des adresses temporaires.
Le tableau suivant présente les mots-clés utilisés dans le fichier ndpd.conf.
Tableau 11–2 Mots-clés de /etc/inet/ndpd.conf
Variable |
Description |
---|---|
ifdefault |
Spécifie le comportement du routeur pour toutes les interfaces. Utilisez la syntaxe suivante pour définir les paramètres du routeur et les valeurs correspondantes : ifdefault [valeur variable] |
prefixdefault |
Spécifie le comportement par défaut pour la publication du préfixe. Utilisez la syntaxe suivante pour définir les paramètres du routeur et les valeurs correspondantes : prefixdefault [valeur variable] |
if |
Définit les paramètres de l'interface. Utilisez la syntaxe suivante : if interface [valeur variable] |
prefix |
Publie les informations du préfixe par interface. Utilisez la syntaxe suivante : prefix préfixe/longueur interface [valeur variable] |
Dans le fichier ndpd.conf, vous utilisez des mots-clés du tableau avec jeu de variables de configuration du routeur. Ces variables sont définies en détail dans le document RFC 2461, Neighbor Discovery for IP Version 6 (IPv6).
Le tableau suivant répertorie les variables de configuration d'une interface et fournit une brève définition de chacune.
Tableau 11–3 Variables de configuration d'interface du fichier /etc/inet/ndpd.conf
Variable |
Par défaut |
Définition |
---|---|---|
AdvRetransTimer |
0 |
Spécifie la valeur du champ Retrans Timer pour la publication de messages envoyés par le routeur. |
AdvCurHopLimit |
Diamètre actuel du réseau Internet |
Spécifie la valeur à entrer dans le champ Hop Limit pour la publication de messages envoyés par le routeur. |
AdvDefaultLifetime |
3 + MaxRtrAdvInterval |
Spécifie la durée de vie par défaut des publications du routeur. |
AdvLinkMTU |
0 |
Spécifie une valeur d'unité de transmission maximale (MTU) que le routeur doit envoyer. Une valeur nulle indique que ne routeur ne spécifie pas d'options MTU. |
AdvManaged Flag |
False |
Spécifie la valeur à entrer dans l'indicateur de configuration de la gestion des adresses pour la publication du routeur. |
AdvOtherConfigFlag |
False |
Spécifie la valeur à entrer dans l'indicateur de configuration des autres paquets avec état pour la publication du routeur. |
AdvReachableTime |
0 |
Spécifie la valeur du champ Reachable Time pour la publication de messages envoyés par le routeur. |
AdvSendAdvertisements |
False |
Indique si le nœud doit envoyer des publications et répondre aux requêtes du routeur. Vous devez définir explicitement la variable sur TRUE dans le fichier ndpd.conf afin d'activer les fonctions de publication du routeur. Pour plus d'informations, reportez-vous à la section Procédure de configuration d'un routeur compatible IPv6. |
DupAddrDetect Transmits |
1 |
Définit le nombre de messages de requête voisine consécutifs que le protocole Neighbor Discovery doit envoyer lors de la détection d'adresses du nœud local dupliquées. |
MaxRtrAdvInterval |
600 secondes |
Spécifie le temps d'attente maximal lors de l'envoi de publications de multidiffusion non requises. |
MinRtrAdvInterval |
200 secondes |
Spécifie le temps d'attente minimal lors de l'envoi de publications de multidiffusion non requises. |
StatelessAddrConf |
True |
Détermine si le nœud configure son adresse IPv6 par le biais de la configuration automatique des adresses sans état. Si la valeur False est déclarée dans le fichier ndpd.conf, l'adresse doit être configurée manuellement. Pour plus d'informations, reportez-vous à la section Procédure de configuration d'un jeton IPv6 spécifié par l'utilisateur. |
TmpAddrsEnabled |
False |
Indique si une adresse temporaire doit être créée pour toutes les interfaces ou pour une interface particulière d'un nœud. Pour plus d'informations, reportez-vous à la section Procédure de configuration d'une adresse temporaire. |
TmpMaxDesyncFactor |
600 secondes |
Spécifie une valeur aléatoire à soustraire de la variable de durée de vie préférée TmpPreferredLifetime au démarrage de la commande in.ndpd. L'objectif de la variable TmpMaxDesyncFactor est d'éviter que tous les systèmes de votre réseau ne régénèrent leurs adresses temporaires en même temps. TmpMaxDesyncFactor permet de remplacer la limite supérieure par cette valeur. |
TmpPreferredLifetime |
False |
Définit la durée de vie préférée d'une adresse temporaire. Pour plus d'informations, reportez-vous à la section Procédure de configuration d'une adresse temporaire. |
TmpRegenAdvance |
False |
Spécifie à l'avance la durée d'obtention d'une désapprobation pour une adresse temporaire. Pour plus d'informations, reportez-vous à la section Procédure de configuration d'une adresse temporaire. |
TmpValidLifetime |
False |
Définit la durée de vie correcte d'une adresse temporaire. Pour plus d'informations, reportez-vous à la section Procédure de configuration d'une adresse temporaire. |
Le tableau suivant répertorie les variables utilisées pour configurer les préfixes IPv6.
Tableau 11–4 Variables de configuration de préfixe du fichier /etc/inet/ndpd.conf
Variable |
Par défaut |
Définition |
---|---|---|
AdvAutonomousFlag |
True |
Spécifie la valeur à entrer dans le champ Autonomous Flag figurant dans les informations sur le préfixe. |
AdvOnLinkFlag |
True
|
Spécifie la valeur à entrer dans l'indicateur on-link "L-bit" figurant dans les informations sur le préfixe. |
AdvPreferredExpiration |
Non définie |
Spécifie la date d'expiration préférée du préfixe. |
AdvPreferredLifetime |
604 800 secondes |
Spécifie la valeur à entrer pour la durée de vie préférée dans les informations sur le préfixe. |
AdvValidExpiration |
Non définie |
Spécifie la date d'expiration correcte du préfixe. |
AdvValidLifetime |
2 592 000 secondes |
Spécifie la durée de vie correcte du préfixe qui est configurée. |
L'exemple suivant répertorie les mots-clés et les variables de configuration utilisés dans le fichier ndpd.conf. Supprimez le commentaire (#) pour activer la variable.
# ifdefault [variable-value ]* # prefixdefault [variable-value ]* # if ifname [variable-value ]* # prefix prefix/length ifname # # Per interface configuration variables # #DupAddrDetectTransmits #AdvSendAdvertisements #MaxRtrAdvInterval #MinRtrAdvInterval #AdvManagedFlag #AdvOtherConfigFlag #AdvLinkMTU #AdvReachableTime #AdvRetransTimer #AdvCurHopLimit #AdvDefaultLifetime # # Per Prefix: AdvPrefixList configuration variables # # #AdvValidLifetime #AdvOnLinkFlag #AdvPreferredLifetime #AdvAutonomousFlag #AdvValidExpiration #AdvPreferredExpiration ifdefault AdvReachableTime 30000 AdvRetransTimer 2000 prefixdefault AdvValidLifetime 240m AdvPreferredLifetime 120m if qe0 AdvSendAdvertisements 1 prefix 2:0:0:56::/64 qe0 prefix fec0:0:0:56::/64 qe0 if qe1 AdvSendAdvertisements 1 prefix 2:0:0:55::/64 qe1 prefix fec0:0:0:56::/64 qe1 if hme1 AdvSendAdvertisements 1 prefix 2002:8192:56bb:1::/64 qfe0 if hme1 AdvSendAdvertisements 1 prefix 2002:8192:56bb:2::/64 hme1 |
IPv6 utilise le fichier /etc/hostname6.interface au démarrage afin de définir automatiquement les interfaces logiques IPv6. Si vous activez le protocole IPv6 lors de l'installation de Oracle Solaris, le programme d'installation crée un fichier /etc/hostname6.interface pour l'interface réseau principale en plus du fichier /etc/hostname. interface.
Si plus d'une interface physique est détectée lors de l'installation, vous êtes invité à configurer ces interfaces. Le programme d'installation crée des fichiers de configuration d'interface IPv4 physique et des fichiers de configuration d'interface IPv6 logique pour toute interface supplémentaire indiquée.
Tout comme les interfaces IPv4, les interfaces IPv6 peuvent être configurées manuellement après l'installation de Oracle Solaris. Vous pouvez créer un fichier /etc/hostname6. interface pour toute nouvelle interface. Pour connaître la procédure de configuration manuelle d'une interface, reportez-vous à la section Gestion des interfaces dans Solaris 10 3/05 ou au Chapitre 6Administration d'interfaces réseau (tâches).
Le nom des nouveaux fichiers de configuration d'interface peut avoir la syntaxe suivante :
hostname.interface hostname6.interface |
La variable interface possède la syntaxe suivante :
dev[.module[.module ...]]PPA |
Indique un périphérique d'interface réseau. Le périphérique peut être une interface réseau physique, telle que eri ou qfe ou une interface logique de type tunnel. Pour de plus amples informations, reportez-vous à la section Fichier de configuration d'interface IPv6.
Répertorie un ou plusieurs modules STREAMS à empiler sur le périphérique lorsque celui-ci est monté.
Indique le point d'attache physique.
La syntaxe [.[.]] est également acceptée.
Exemples de noms de fichier de configuration IPv6 valides :
hostname6.qfe0 hostname.ip.tun0 hostname.ip6.tun0 hostname6.ip6to4tun0 hostname6.ip.tun0 hostname6.ip6.tun0 |
Le fichier /etc/inet/ipaddrsel.conf contient la table des règles de sélection d'adresse IPv6 par défaut. Si vous avez activé le protocole IPv6 lors de l'installation de Oracle Solaris, ce fichier contient les éléments présentés dans le Tableau 11–5.
Vous pouvez modifier le contenu de /etc/inet/ipaddrsel.conf. Toutefois, cette opération n'est pas recommandée. Si cela s'avère nécessaire, reportez-vous à la procédure décrite à la section Administration de la table des règles de sélection d'adresses IPv6. Pour plus d'informations sur le fichier ippaddrsel.conf, reportez-vous à la section Raisons pour lesquelles le tableau des règles de sélection d'adresses IPv6 doit être modifié ainsi qu'à la page de manuel ipaddrsel.conf(4).
Cette section décrit les commandes ajoutées lors de l'implémentation du protocole IPv6 sous Oracle Solaris. Les commandes existantes qui ont été modifiées pour prendre en charge IPv6 y sont également détaillées.
La commande ipaddrsel permet de modifier le tableau des règles de sélection des adresses IPv6 par défaut.
Le noyau Oracle Solaris utilise la table des règles de sélection des adresses IPv6 par défaut pour le classement des adresses de destination et la sélection des adresses sources pour les en-têtes de paquet IPv6. Le fichier /etc/inet/ipaddrsel.conf contient ce tableau de règles.
Le tableau suivant répertorie les formats d'adresse par défaut ainsi que les priorités de chacune telles qu'elles doivent figurer dans le tableau de règles. Vous pouvez rechercher des informations techniques sur la sélection d'adresses IPv6 dans la page de manuel inet6(7P).
Tableau 11–5 Tableau des règles de sélection des adresses IPv6 par défaut
Préfixe |
Priorité |
Définition |
---|---|---|
::1/128 |
50 |
Loopback |
::/0 |
40 |
Par défaut |
2002::/16 |
30 |
6to4 |
::/96 |
20 |
IPv4 Compatible |
::ffff:0:0/96 |
10 |
IPv4 |
Dans ce tableau, les préfixes IPv6 (::1/128 et ::/0) ont la priorité sur les adresses 6to4 (2002::/16) et les adresses IPv4 (::/96 et ::ffff:0:0/96). Par conséquent, le noyau choisit par défaut l'adresse IPv6 globale de l'interface pour les paquets envoyés vers une autre destination IPv6. L'adresse IPv4 de l'interface est moins prioritaire, notamment pour les paquets envoyés vers une destination IPv6. Étant donné l'adresse IPv6 source sélectionnée, le noyau utilise également le format IPv6 pour l'adresse de destination.
En règle générale, le tableau des règles de sélection d'adresses IPv6 par défaut n'a pas besoin d'être modifié. En cas de modification nécessaire, exécutez la commande ipaddrsel.
Les situations suivantes nécessitent une modification du tableau :
Si le système possède une interface qui est utilisée pour un tunnel 6to4, vous pouvez définir une priorité plus élevée pour les adresses 6to4.
Si vous souhaitez qu'une adresse source particulière communique avec une adresse de destination particulière, vous pouvez ajouter ces adresses au tableau de règles. Ensuite, vous pouvez les marquer comme des adresses préférées à l'aide de la commande ifconfig.
Si vous voulez que les adresses IPv4 aient la priorité sur les adresses IPv6, vous pouvez remplacer la priorité de ::ffff:0:0/96 par un chiffre plus élevé.
Si vous devez assigner une priorité plus élevée à des adresses désapprouvées, vous pouvez ajouter ces adresses au tableau de règles. Prenons l'exemple des adresses de site locales, actuellement désapprouvées sur le réseau IPv6. Ces adresses possèdent le préfixe fec0::/10 . Vous pouvez modifier le tableau de règles afin de définir une priorité plus élevée pour ces adresses.
Pour de plus amples informations sur la commande ipaddrsel, reportez-vous à la page de manuel ipaddrsel(1M).
La création de tunnel 6to4 permet à des sites 6to4 isolés de communiquer. Cependant, pour transférer des paquets vers un site IPv6 natif et non-6to4, le routeur 6to4 doit être relié au routeur relais 6to4 par un tunnel. Le routeur relais 6to4 transfère ensuite les paquets 6to4 au réseau IPv6 et, finalement, au site IPv6 natif. Si un site 6to4 doit échanger des données avec un site IPv6, vous pouvez créer le tunnel approprié à l'aide de la commande 6to4relay.
Sous Oracle Solaris, la liaison de tunnels à des routeurs relais est désactivée car l'utilisation des routeurs relais n'est pas sécurisée. Avant de relier un tunnel à un routeur relais 6to4, vous devez être conscient des problèmes qui peuvent survenir avec ce type de scénario. Pour de plus amples informations sur les routeurs relais 6to4, reportez-vous à la section Informations importantes pour la création de tunnels vers un routeur relais 6to4. Pour activer la prise en charge d'un routeur relais 6to4, vous pouvez suivre la procédure indiquée à la section Procédure de configuration d'un tunnel 6to4.
La commande 6to4relay possède la syntaxe suivante :
6to4relay -e [-a IPv4-address] -d -h |
Assure la prise en charge de tunnels entre le routeur 6to4 et un routeur relais 6to4 anycast. Ainsi, l'adresse du point d'extrémité du tunnel est définie sur 192.88.99.1 , soit l'adresse du groupe anycast de routeurs relais 6to4.
Assure la prise en charge de tunnels entre le routeur 6to4 et un routeur relais 6to4 possédant l'adresse IPv4 spécifiée.
Désactive la prise en charge de tunnels vers un routeur relais 6to4 (paramètre par défaut de Oracle Solaris).
Affiche l'aide concernant la commande 6to4relay.
Pour plus d'informations, reportez-vous à la page de manuel 6to4relay(1M).
La commande 6to4relay, sans argument, affiche le statut actuel de la prise en charge des routeurs relais 6to4. Cet exemple indique la sortie par défaut de l'implémentation du protocole IPv6 sous Oracle Solaris.
# /usr/sbin/6to4relay 6to4relay:6to4 Relay Router communication support is disabled |
Lorsque la prise ne charge des routeurs relais est activée, la commande 6to4relay affiche la sortie suivante :
# /usr/sbin/6to4relay 6to4relay:6to4 Relay Router communication support is enabled IPv4 destination address of Relay Router=192.88.99.1 |
Si vous spécifiez l'option -a et une adresse IPv4 dans la commande 6to4relay, l'adresse IPv4 fournie avec l'option - a remplace l'adresse 192.88.99.1.
La commande 6to4relay ne signale pas l'exécution des options -d, -e et -a adresse IPv4. Cependant, elle n'affiche aucun message d'erreur lié à l'exécution de ces options.
La commande ifconfig permet de monter les interfaces IPv6 et le module de mise sous tunnel. ifconfig utilise un jeu étendu de ioctls pour configurer à la fois les interfaces réseau IPv4 et IPv6. Les options ifconfig qui prennent en charge les opérations IPv6 sont répertoriées ci-dessous. Pour connaître les différentes tâches IPv4 et IPv6 qui impliquent l'exécution de la commande ifconfig, reportez-vous à la section Contrôle de la configuration de l'interface avec la commande ifconfig.
Définit l'index de l'interface.
Définit la source ou la destination du tunnel.
Crée l'interface logique suivante.
Supprime une interface logique possédant une adresse IP spécifique.
Définit l'adresse de destination point à point pour une interface.
Définit une adresse et/ou un masque de réseau pour une interface.
Définit l'adresse de sous-réseau d'une interface.
Active ou désactive la transmission de paquets sur une interface.
Le Chapitre 7Configuration d'un réseau IPv6 (tâches) fournit les procédures de configuration des réseaux IPv6.
La commande ifconfig suivante crée une interface logique hme0:3 :
# ifconfig hme0 inet6 addif up Created new logical interface hme0:3 |
Cette forme de ifconfig vérifie la création de l'interface :
# ifconfig hme0:3 inet6 hme0:3: flags=2000841<UP,RUNNING,MULTICAST,IPv6> mtu 1500 index 2 inet6 inet6 fe80::203:baff:fe11:b321/10 |
La commande ifconfig suivante supprime une interface logique hme0:3 :
# ifconfig hme0:3 inet6 down # ifconfig hme0 inet6 removeif 1234::5678 |
# ifconfig ip.tun0 inet6 plumb index 13 |
Ouvre le tunnel à associer au nom de l'interface physique.
# ifconfig ip.tun0 inet6 ip.tun0: flags=2200850<POINTOPOINT,RUNNING,MULTICAST,NONUD, #IPv6> mtu 1480 index 13 inet tunnel src 0.0.0.0 inet6 fe80::/10 --> :: |
Configure les flux nécessaires au protocole TCP/IP pour utiliser le périphérique du tunnel et signaler son statut.
# ifconfig ip.tun0 inet6 tsrc 120.46.86.158 tdst 120.46.86.122 |
Configure l'adresse source et l'adresse cible du tunnel.
# ifconfig ip.tun0 inet6 ip.tun0: flags=2200850<POINTOPOINT,RUNNING,MULTICAST,NONUD, IPv6> mtu 1480 index 13 inet tunnel src 120.46.86.158 tunnel dst 120.46.86.122 inet6 fe80::8192:569e/10 --> fe80::8192:567a |
Indique le nouveau statut du périphérique après la configuration.
Dans l'exemple suivant, une configuration de pseudointerface 6to4 utilise l'ID de sous-réseau 1 et spécifie l'ID hôte sous forme hexadécimale.
# ifconfig ip.6to4tun0 inet6 plumb # ifconfig ip.6to4tun0 inet tsrc 129.146.86.187 \ 2002:8192:56bb:1::8192:56bb/64 up |
# ifconfig ip.6to4tun0 inet6 ip.6to4tun0: flags=2200041<UP,RUNNING,NONUD,IPv6>mtu 1480 index 11 inet tunnel src 129.146.86.187 tunnel hop limit 60 inet6 2002:8192:56bb:1::8192:56bb/64 |
Voici une forme courte de la commande permettant de configurer un tunnel 6to4.
# ifconfig ip.6to4tun0 inet6 plumb # ifconfig ip.6to4tun0 inet tsrc 129.146.86.187 up |
# ifconfig ip.6to4tun0 inet6 ip.6to4tun0: flags=2200041<UP,RUNNING,NONUD,IPv6>mtu 1480 index 11 inet tunnel src 129.146.86.187 tunnel hop limit 60 inet6 2002:8192:56bb::1/64 |
La commande netstat affiche le statut des réseaux IPv4 et IPv6. Vous pouvez choisir les informations de protocole à afficher en définissant la valeur de DEFAULT_IP dans le fichier /etc/default/inet_type ou en utilisant l'option -f dans la ligne de commande. Avec une valeur de DEFAULT_IP permanente, vous vous assurez que la commande netstat affiche uniquement les informations IPv4. Vous pouvez ignorer ce paramètre et utiliser l'option -f. Pour plus d'informations sur le fichier inet_type , reportez-vous à la page de manuel inet_type(4).
L'option -p de la commande netstat affiche la table des connexions réseau-média, c'est-à-dire la table des protocoles de résolution d'adresse pour l'IPv4 et le cache voisin pour l'IPv6. Pour de plus amples informations, reportez-vous à la page de manuel netstat(1M) La section Affichage du statut des sockets décrit les procédures impliquant l'exécution de cette commande.
La commande snoop permet de capturer des paquets IPv4 et IPv6. Cette commande peut s'afficher avec des en-têtes IPv6, des en-têtes d'extension IPv6, des en-têtes ICMPv6 et des données de protocole Neighbor Discovery. Par défaut, la commande snoop affiche les deux types de paquet (IPv4 et IPv6). Pour afficher soit l'un, soit l'autre, spécifiez le mot-clé de protocole ip ou ip6 avec la commande snoop. L'option de filtrage IPv6 vous permet de filtrer tous les paquets IPv4 et IPv6 et d'afficher uniquement les paquets IPv6. Pour plus d'informations, reportez-vous à la page de manuel snoop(1M) La section Contrôle du trafic réseau IPv6 décrit les procédures implicant l'exécution de la commande snoop.
La commande route fonctionne sur les routes IPv4 (par défaut) et IPv6. Pour réaliser des opérations sur les routes IPv6, tapez l'option -inet6 immédiatement à la suite de la commande route dans la ligne de commande. Pour plus d'informations, reportez-vous à la page de manuel route(1M).
La commande ping se sert des protocoles IPv4 et IPv6 pour sonder les hôtes cibles. Le choix du protocole dépend des adresses renvoyées par le serveur de noms pour l'hôte cible spécifique. Par défaut, si ce serveur renvoie une adresse IPv6 pour l'hôte cible, la commande ping utilise le protocole IPv6. S'il renvoie une adresse IPv4, la commande ping utilise le protocole IPv4. Pour ignorer cette action, vous pouvez taper l'option -A dans la ligne de commande et spécifier le protocole à utiliser.
Pour de plus amples informations, reportez-vous à la page de manuel ping(1M) La section Test des hôtes distants à l'aide de la commande ping décrit les procédures implicant l'exécution de la commande ping .
Vous pouvez exécuter la commande traceroute pour tracer les routes IPv4 et IPv6 vers un hôte spécifique. Du point de vue du protocole, traceroute utilise le même algorithme que la commande ping. Pour ignorer ce choix, tapez l'option -A dans la ligne de commande. Vous pouvez tracer chaque route vers chaque adresse d'un hôte multiréseau en tapant l'option -a dans la ligne de commande.
Pour de plus amples informations, reportez-vous à la page de manuel traceroute(1M) La section Affichage des informations de routage à l'aide de la commande traceroute décrit les procédures qui impliquent l'exécution de la commande traceroute.
Cette section présente les démons liés à IPv6.
Le démon in.ndpd implémente le protocole IPv6 Neighbor Discovery ainsi que celui de découverte de routeur. Il implémente également la configuration automatique d'adresse IPv6. Les options suivantes sont prises en charge par in.ndpd.
Active le débogage.
Active le débogage dans le cadre d'événements spécifiques.
Spécifie un fichier de données de configuration spécifique au lieu du fichier /etc/inet/ndpd.conf.
Imprime les informations associées à chaque interface.
Ne met pas en boucle les publications du routeur.
Ignore la réception de paquets.
Spécifie le mode détaillé en faisant état de plusieurs types de message de diagnostic.
Active le suivi des paquets.
Le démon in.ndpd est contrôlé par les paramètres définis dans le fichier de configuration /etc/inet/ndpd.conf et par ceux du fichier de démarrage /var/inet/ndpd_state. interface qui s'appliquent.
Lorsque le fichier /etc/inet/ndpd.conf existe, il est analysé et utilisé pour configurer un nœud en tant que routeur. Le Tableau 11–2 répertorie les mots-clés corrects susceptibles de figurer dans ce fichier. Lors de l'initialisation d'un hôte, les routeurs risquent de ne pas être disponibles immédiatement. Les paquets publiés par le routeur risquent d'être abandonnés. En outre, les paquets risquent de ne pas atteindre l'hôte.
Le fichier /var/inet/ndpd_state.interface est un fichier d'état. Ce fichier est régulièrement mis à jour par chaque nœud. En cas de défaillance et de redémarrage du nœud, ce dernier peut configurer ses interfaces en l'absence de routeurs. Ce fichier contient l'adresse de l'interface, l'heure de la dernière mise à jour du fichier et la durée de validité du fichier. Il contient également d'autres paramètres “hérités” de précédentes publications de routeur.
Il est inutile de modifier le contenu des fichiers d'état. Le démon in.ndpd assure la maintenance automatique des fichiers d'état.
Consultez les pages de manuel in.ndpd(1M) et ndpd.conf(4) pour obtenir des listes des variables de configuration et des valeurs acceptables.
Le démon in.ripngd implémente les informations de RIPng (Routing Information Protocol next-generation, protocole d'informations de routage nouvelle génération) pour les routeurs IPv6. Le RIPng définit l'équivalent IPv6 de RIP (Routing Information Protocol, protocole d'informations de routage). Lorsque vous configurez un routeur IPv6 avec la commande routeadm et activez le routage IPv6, le démon in.ripngd implémente RIPng sur le routeur.
Vous trouverez ci-dessous les options RIPng prises en charge.
n spécifie le numéro de port alternatif utilisé pour l'envoi ou la réception de paquets RIPnG.
Supprime les informations de routage.
Force le routage d'informations même si le démon fait office de routeur.
Supprime l'utilisation du poison reverse.
Si in.ripngd n'agit pas en tant que routeur, le démon saisit uniquement une route par défaut pour chaque routeur.
Une application de serveur compatible IPv6 peut gérer les requêtes IPv4 et IPv6, ou les requêtes IPv6 uniquement. Le serveur gère toujours les requêtes par le biais d'un socket IPv6. En outre, le serveur utilise le même protocole qu'utilise le client correspondant. Pour ajouter ou modifier un service pour IPv6, utilisez les commandes disponibles à partir du service SMF (Service Management Facility, utilitaire de gestion des services).
Pour obtenir des informations sur les commandes SMF, reportez-vous à la section SMF Command-Line Administrative Utilities du System Administration Guide: Basic Administration .
Pour obtenir une tâche d'exemple utilisant le service SMF pour configurer un manifeste de service IPv4 s'exécutant sur SCTP, reportez-vous à la section Ajout de services utilisant le protocole SCTP.
Pour configurer un service IPv6, vous devez vous assurer que la valeur du champ proto dans le profil inetadm pour ce service répertorie la valeur adéquate :
Pour un service assurant la gestion de requêtes IPv4 et IPv6, sélectionnez tcp6, udp6 ou sctp. Une valeur proto de tcp6, udp6 ou sctp6 a pour conséquence de faire passer inetd sur un socket IPv6 vers le serveur. Le serveur contient une adresse mappée IPv4 au cas où un client IPv4 recevrait une requête.
Pour un service qui gère uniquement les requêtes IPv6, sélectionnez tcp6only ou udp6only. Si proto a l'une de ces valeurs, inetd passe le serveur à un socket IPv6.
Si vous remplacez une commande Oracle Solaris par une autre implémentation, vous devez vous assurer que l'implémentation de ce service prend en charge le protocole IPv6. Si l'implémentation ne prend pas IPv6 en charge, vous devez spécifier la valeur proto en tant que tcp, udp ou sctp.
Voici un profil qui résulte de l'exécution de inetadm pour un manifeste de service echo prenant IPv4 et IPv6 en charge, et s'exécute sur SCTP :
# inetadm -l svc:/network/echo:sctp_stream SCOPE NAME=VALUE name="echo" endpoint_type="stream" proto="sctp6" isrpc=FALSE wait=FALSE exec="/usr/lib/inet/in.echod -s" user="root" default bind_addr="" default bind_fail_max=-1 default bind_fail_interval=-1 default max_con_rate=-1 default max_copies=-1 default con_rate_offline=-1 default failrate_cnt=40 default failrate_interval=60 default inherit_env=TRUE default tcp_trace=FALSE default tcp_wrappers=FALSE |
La syntaxe suivante permet de modifier la valeur du champ proto :
# inetadm -m FMRI proto="transport-protocols" |
Tous les serveurs fournis avec le logiciel Oracle Solaris ne nécessitent qu'une entrée de profil spécifiant proto en tant que tcp6, udp6 ou sctp6. Cependant, le serveur shell distant (shell) et le serveur d'exécution distant (exec) sont à présent composés d'une instance de service unique, nécessitant une valeur proto contenant les valeurs tcp et tcp6only. Par exemple, pour définir la valeur proto pour shell, émettez la commande suivante :
# inetadm -m network/shell:default proto="tcp,tcp6only" |
Consultez les extensions IPv6 de l'API Socket dans la section Programming Interfaces Guide pour obtenir des informations supplémentaires sur l'écriture de serveurs compatibles IPv6 qui utilisent des sockets.
Gardez les éléments suivants à l'esprit lorsque vous ajoutez ou modifiez un service pour IPv6 :
Vous devez spécifier la valeur proto en tant que tcp6, sctp6 ou udp6 afin d'activer les connexions IPv4 ou IPv6. Si vous spécifiez la valeur pour proto en tant que tcp, sctp ou udp, le service n'utilise qu'IPv4.
Bien qu'il soit possible d'ajouter une instance de service utilisant des sockets SCTP de style un à plusieurs à inetd, il est déconseillé de le faire. inetd ne fonctionne pas avec les sockets SCTP de style un à plusieurs.
Si un service nécessite deux entrées en raison de propriétés wait-status ou exec différentes, vous devez créer deux instances/services à partir du service d'origine.
IPv6 présente le protocole Neighbor Discovery, comme décrit dans le document RFC 2461, Neighbor Discovery for IP Version 6 (IPv6). Pour obtenir une présentation des principales fonctionnalités de la détection des voisins, reportez-vous à la section Présentation du protocole de détection de voisins IPv6.
Cette section décrit les fonctionnalités suivantes du protocole ND :
La détection de voisins définit cinq nouveaux messages ICMP (Internet Control Message Protocol, protocole de messages de contrôle Internet). Les messages remplissent les fonctions suivantes :
Sollicitation de routeur – Lorsqu'une interface est activée, les hôtes peuvent demander des messages de sollicitation de routeur. Les sollicitations demandent aux routeurs de générer immédiatement des publications de routeurs, plutôt qu'à la prochaine heure prévue.
Publication de routeur – Les routeurs publient leur présence, divers liens de paramètres et divers liens de paramètres Internet. Les routeurs effectuent des publications régulières ou en réponse à un message de sollicitation de routeur. Les publications de routeur contiennent des préfixes utilisés pour la détermination sur lien ou la configuration d'adresse, une valeur de limite de saut recommandée, et ainsi de suite.
Sollicitation de voisin – Les nœuds envoient des messages de sollicitation de voisins afin de déterminer l'adresse de couche liaison du voisin. Les messages de sollicitation de voisin sont également envoyés afin de vérifier qu'un voisin est toujours accessible par une adresse de couche liaison mise en cache. Les sollicitations s'utilisent également pour la détection d'adresses dupliquées.
Publication de voisins – Un nœud envoie des messages de publication de voisinage en réponse à un message de sollicitation de voisinage Le nœud peut également envoyer des publications de voisinage non sollicitées pour signaler une modification de l'adresse de couche liaison.
Redirection – Les routeurs utilisent les messages de redirection afin d'informer les hôtes de l'existence d'un meilleur saut pour une destination ou que la destination se trouve sur la même liaison.
Cette section comprend une présentation des étapes typiques effectuées par une interface lors d'une configuration automatique. La configuration automatique s'effectue uniquement sur des liaisons compatibles multicast.
Une interface compatible multicast est activée, par exemple, lors du démarrage système d'un nœud.
Le nœud démarre le processus de configuration automatique en générant une adresse lien-local pour l'interface.
L'adresse lien-local est formée à partir de l'adresse MAC (Media Access Control) de l'interface.
Le nœud envoie un message de sollicitation de voisin contenant l'adresse lien-local provisoire en guise de cible.
Le message a pour objectif de vérifier que l'adresse possible n'est pas déjà utilisée par un autre nœud sur la liaison. Une fois la vérification effectuée, l'adresse lien-local peut être assignée à l'interface.
Si un autre nœud utilise déjà l'adresse proposée, celui-ci renvoie une publication de voisin indiquant que l'adresse est déjà en cours d'utilisation.
Si un autre nœud tente également d'utiliser la même adresse, le nœud envoie également une sollicitation de voisinage pour la cible.
Le nombre de transmissions ou de retransmissions de sollicitation de voisins, ainsi que le temps d'attente entre sollicitations, sont spécifiques aux liaisons. Au besoin, vous pouvez définir ces paramètres.
Si un nœud détermine que son adresse lien-local possible n'est pas unique, la configuration automatique est interrompue. Dans ce cas, vous devrez configurer manuellement l'adresse lien-local de l'interface.
Pour simplifier la récupération, vous pouvez fournir un autre ID d'interface qui remplace l'identifiant par défaut. Ensuite, le mécanisme de configuration automatique peut reprendre, en utilisant le nouvel ID d'interface, qui est à priori unique.
Lorsqu'un nœud détermine l'unicité de sa future adresse lien-local, il assigne celle-ci à l'interface.
Le nœud dispose alors d'une connectivité de niveau IP avec les nœuds voisins. Les étapes restantes de la configuration automatique sont effectuées exclusivement par les hôtes.
La phase suivante de la configuration automatique consiste à obtenir une publication de routeur ou à déterminer une absence totale de routeurs. Si les routeurs sont présents, ils envoient des publications de routeur qui spécifient le type de configuration automatique que doit effectuer un hôte.
Les routers envoient des publications de routeur à intervalles réguliers. Cependant, le temps d'attente entre publications successives est en règle générale plus long que le temps d'attente possible d'un hôte effectuant la configuration automatique. Afin d'obtenir une publication dans les plus brefs délais, un hôte envoie une ou plusieurs sollicitations de routeur au groupe multicast tous routeurs.
La publication de routeur contient également des variables de préfixe avec des informations utilisées par la configuration automatique d'adresse sans état pour la génération de préfixes. Le champ de configuration automatique d'adresse sans état dans les publications de routeur sont traitées indépendamment. Un champ d'option contenant les informations de préfixe, l'indicateur de configuration automatique d'adresse, indique si l'option s'applique également à la configuration automatique sans état. Si le champ d'option s'y applique, des champs d'option supplémentaires contiennent un préfixe de sous-réseau avec des valeurs de durée de vie. Ces valeurs indiquent la durée de validité et de préférence des adresses créées à partir du préfixe.
Dans la mesure où les routeurs génèrent régulièrement des publications de routeur, les hôtes reçoivent de nouvelles publications en continu. Les hôtes compatibles IPv6 traitent les informations contenues dans chaque publication. Les hôtes ajoutent des informations. Ils actualisent également les informations reçues dans les publications précédentes.
Pour des raisons de sécurité, l'unicité de toutes les adresses doit être vérifiée, préalablement à leur assignation à une interface. La situation est différente pour les adresses créées par configuration automatique sans état. L'unicité d'une adresse est déterminée principalement par la partie de l'adresse formée à partir d'un ID d'interface. Par conséquent, si un nœud a déjà vérifié l'unicité d'une adresse lien-local, il est inutile de tester les adresses supplémentaires individuellement. Les adresses doivent être créées à partir du même ID d'interface. Toutes les adresses obtenues manuellement doivent par contre être testées individuellement pour leur unicité. Les administrateurs système de certains sites pensent que les bénéfices de la détection d'adresses dupliquées ne vaut pas le temps système qu'elle utilise. Pour ces sites, l'utilisation de la détection des adresses dupliquées peut être désactivée en définissant un indicateur de configuration par interface.
Pour accélérer le processus de configuration automatique, un hôte peut générer son adresse lien-local et vérifier son unicité, pendant que l'hôte attend une publication de routeur. Un routeur peut retarder une réponse à une sollicitation de routeur de quelques secondes. Par conséquent, le temps total nécessaire à la configuration automatique peut être bien plus long si les deux étapes sont effectuées en série.
La détection de voisins utilise les messages de sollicitation de voisin pour déterminer si plusieurs nœuds sont assignés à la même adresse unicast. La détection d'inaccessibilité de voisin détecte la défaillance d'un voisin ou du chemin de transfert du voisin. Cette détection nécessite une confirmation de la réception des paquets par le voisin. La détection d'inaccessibilité de voisins détermine également que les paquets sont traités correctement par la couche IP du nœud.
La détection d'inaccessibilité de voisin utilise les confirmations en provenance de deux sources : les protocoles de couche supérieure et les messages de sollicitation de voisin. Lorsque c'est possible, les protocoles de couche supérieure fournissent une confirmation positive de la progression d'une connexion. Par exemple, à la réception d'accusés de réception TCP, il est confirmé que les données précédemment envoyées ont été livrées correctement.
Lorsqu'un nœud n'obtient pas de confirmation en provenance des protocoles de couche supérieure, le nœud envoie des messages de sollicitation de voisins. Ces messages sollicitent des publications de voisinage en tant que confirmation d'accessibilité à partir du prochain saut. Pour réduire le trafic réseau inutile, les messages de sonde sont envoyés uniquement au nœud envoyant des paquets activement.
Pour garantir que toutes les adresses configurées sont susceptibles d'être uniques sur un lien donné, les nœuds exécutent un algorithme de détection d'adresse dupliquée sur les adresses. Les nœuds doivent exécuter l'algorithme avant d'assigner les adresses à une interface. L'algorithme de détection d'adresses dupliquées est exécuté sur toutes les adresses.
Le processus de configuration automatique décrit dans cette section s'applique uniquement aux hôtes et non aux routeurs. Dans la mesure où la configuration automatique utilise des informations publiées par les routeurs, ces derniers doivent être configurés différemment. Cependant, les routeurs génèrent des adresses lien-local à l'aide du mécanisme décrit dans ce chapitre. En outre, les routeurs doivent réussir l'algorithme de détection d'adresses dupliquées sur toutes les adresses préalablement à l'assignation d'une adresse à une interface.
Un routeur qui accepte les paquets à la place d'une adresse cible peut émettre des publications de voisin impossibles à ignorer. Le routeur peut accepter des paquets pour une adresse cible incapable de répondre aux sollicitations de voisins. L'utilisation de proxy n'est actuellement pas spécifiée. Cependant, la publication de proxy pourrait être utilisée pour la gestion de cas comme ceux de nœuds mobiles qui ont été déplacés hors liaison. Notez que l'utilisation de proxy n'est pas destinée à l'être en tant que mécanisme général de gestion des nœuds qui n'implémentent pas ce protocole.
Les nœuds avec interfaces répliquées peuvent avoir besoin d'équilibrer la charge de la réception de paquets entrants sur plusieurs interfaces réseau situées sur la même liaison. Ces nœuds possèdent plusieurs adresses lien-local assignées à la même interface. Par exemple, un pilote de réseau unique peut représenter plusieurs cartes d'interface réseau en tant qu'interface logique unique possédant plusieurs adresses lien-local.
La gestion de l'équilibrage de charge s'effectue en autorisant les routeurs à omettre l'adresse lien-local source des paquets de publication de routeur. Par conséquent, les voisins doivent utiliser les messages de sollicitation de voisin afin de connaître les adresses lien-local des routeurs. Les messages renvoyés de publication des voisins peuvent contenir des adresses lien-local différentes, selon l'adresse qui a envoyé la demande.
Un nœud qui sait que son adresse lien-local a été modifiée peut envoyer des paquets de publication de voisins multicast non sollicités. Le nœud peut envoyer des paquets multicast à tous les nœuds pour une mise à jour des adresses lien-local mises en cache qui ne sont plus valides. L'envoi de publications non sollicitées constitue uniquement une amélioration des performances. L'algorithme de détection d'inaccessibilité des voisins assure la fiabilité de la détection de la nouvelle adresse par le nœud, bien que le temps d'attente risque d'être légèrement plus long.
La fonctionnalité du protocole ND (Neighbor Discovery, détection des voisins) IPv6 correspond à une combinaison des protocoles IPv4 : ARP (Address Resolution Protocol, protocole de résolution d'adresse), détection de routeur ICMP (Internet Control Message Protocol, protocole de messages de contrôle Internet) et redirection ICMP. IPv4 ne possède pas de protocole ou de mécanisme accepté par tous pour la détection d'inaccessibilité. Cependant, les exigences de l'hôte spécifient les algorithmes possibles pour la détection de passerelles bloquées. La détection de passerelles bloquées est un sous-ensemble des problèmes résolus par la détection d'inaccessibilité de voisins.
La liste suivante compare le protocole de détection de voisins à la suite de protocoles IPv4 associés.
La détection de routeur fait partie du jeu de protocoles IPv6 de base. Les hôtes IPv6 n'ont pas besoin d'émettre la commande snoop aux protocoles de routage pour rechercher un routeur. IPv4 utilise le protocole ARP, la détection de routeur ICMP et la redirection ICMP pour la détection de routeur.
Les publications de routeur IPv6 gèrent les adresses lien-local. Aucun échange de paquet supplémentaire n'est nécessaire pour la résolution de l'adresse lien-local du routeur.
Les publications de routeur gèrent les préfixes de site pour une liaison. Aucun mécanisme séparé n'est nécessaire pour la configuration du masque de réseau, contrairement à IPv4.
Les publications de routeur sont compatibles avec la configuration automatique d'adresse. La configuration automatique n'est pas implémentée dans IPv4.
La détection de voisins permet aux routeurs IPv6 de publier la MTU utilisable pour les hôtes sur la liaison. Par conséquent, tous les nœuds utilisent la même valeur de MTU sur des liaisons ne disposant pas d'une MTU correctement définie. Les hôtes IPv4 sur un même réseau peuvent avoir des MTU différentes.
Contrairement aux adresses de diffusion IPv4, la multidiffusion de résolution d'adresse IPv6 est répartie sur 4 milliards (2^32) d'adresses multicast, ce qui réduit de façon significative les interruptions relatives à la résolution d'adresses sur des nœuds autres que la cible. En outre, les ordinateurs non IPv6 ne doivent pas être éteints.
Les redirections IPv6 contiennent l'adresse lien-local du premier nouveau saut. La résolution d'adresse séparée n'est pas nécessaire lors de la réception d'une redirection.
Il est possible d'associer plusieurs préfixes de site au même réseau IPv6. Par défaut, les hôtes sont informés de tous les préfixes de site locaux par les publications de routeur. Cependant, les routeurs peuvent être configurés afin d'omettre certains ou tous les préfixes des publications de routeur. Dans de tels cas, les hôtes partent du principe que les destinations se trouvent sur des réseaux distants. Par conséquent, les hôtes envoient le trafic aux routeurs. Un routeur peut alors émettre des redirections le cas échéant.
Contrairement à IPv4, le destinataire d'un message IPv6 redirigé part du principe que le nouveau saut suivant se trouve sur le réseau local. Dans IPv4, un hôte ignore les messages de redirection qui spécifient un saut suivant qui ne se trouve pas sur le réseau local, selon le masque de réseau. Le mécanisme de redirection IPv6 est similiaire à l'utilitaire XRedirect d'IPv4. Le mécanisme de redirection est utile sur des liens de non diffusion ou de médias partagés. Sur ces réseaux, les nœuds ne doivent pas effectuer de vérification sur tous les préfixes pour les destinations de liaison locale.
La détection d'inaccessibilité de voisin IPv6 améliore la livraison de paquets en la présence de routeurs défaillants. Cette capacité améliore la livraison de paquets sur des liaisons partiellement défaillantes ou partitionnées. Cette capacité améliore également la livraison de paquet sur des nœuds qui modifient leurs adresses lien-local. Par exemple, les nœuds mobiles peuvent se déplacer hors du réseau local sans aucune perte de connectivité en raison d'anciens caches ARP. IPv4 ne possède pas de méthode correspondante de détection d'inaccessibilité de voisins.
Contrairement au protocole ARP, la détection de voisins détecte les défaillances de demi liaison à l'aide de la détection d'inaccessibilité de voisins. La détection de voisins évite d'envoyer du trafic aux voisins en l'absence de connectivité bidirectionnelle.
En utilisant les adresses lien-local pour identifier les routeurs de façon unique, les hôtes IPv6 peuvent conserver les associations de routeur. La capacité d'identification de routeurs est requise pour les publications de routeur et pour les messages de redirection. Les hôtes doivent conserver les associations de routeur si le site utilise de nouveaux préfixes globaux. IPv4 ne possède pas de méthode comparable d'identification des routeurs.
Dans la mesure où les messages de détection de voisins ont une limite de saut de 255 après réception, le protocole n'est pas affecté par les attaques de mystification en provenance de nœuds hors liaison. Les nœuds IPv4 hors liaison sont eux capables d'envoyer des messages de redirection ICMP. Les nœuds IPv4 hors liaison peuvent également envoyer des messages de publication de routeur.
En plaçant la résolution d'adresse à la couche ICMP, la détection de voisins est moins dépendante de médias que le protocole ARP. Par conséquent, les mécanismes standard d'authentification IP et de sécurité peuvent être utilisés.
Le routage IPv6 est quasiment identique au routage IPv4 sous CIDR (Classless Inter-Domain Routing, routage inter-domaine sans classe). La seule différence est la taille des adresses qui sont de 128 bits dans IPv6 au lieu de 32 bits dans IPv4. Avec des extensions simples, il est possible d'utiliser la totalité des algorithmes de routage d'IPv4 comme OSPF, RIP, IDRP et IS-IS.
IPv6 comprend également des extensions de routage simples qui prennent en charge de nouvelles capacités de routage puissantes. La liste suivante décrit les nouvelles capacités de routage :
sélection de fournisseur en fonction de la stratégie, des performances, des coûts, etc ;
hébergement de mobilité, routage vers emplacement actuel ;
réadressage automatique, routage vers nouvelle adresse.
Les nouvelles capacités de routage s'obtiennent par la création de séquences d'adresses IPv6 utilisant l'option de routage IPv6. Une source IPv6 utilise l'option de routage afin de répertorier un ou plusieurs nœuds intermédiaires, ou groupes topologiques, à visiter en cours d'acheminement vers la destination du paquet. Cette fonction possède énormément de similitudes avec l'option IPv4 de source lâche et de route d'enregistrement.
Pour que les séquences d'adresses soient une fonction générale, les hôtes IPv6 doivent, dans la plupart des cas, inverser les routes d'un paquet reçu par un hôte. Le paquet doit être authentifié à l'aide de l'utilisation de l'en-tête d'authentification IPv6. Le paquet doit contenir des séquences d'adresse afin d'être renvoyé à son point d'origine. Cette technique force les implémentations d'hôtes IPv6 pour la prise en charge de la gestion et de l'inversion des routes source. La gestion et l'inversion des routes source est la clé permettant aux fournisseurs de travailler avec les hôtes qui implémentent les nouvelles capacités IPv6 comme la sélection de fournisseur et les adresses étendues.
Sur des liens compatibles multicast et des liens point à point, chaque routeur envoie régulièrement un paquet de publication de routeur au groupe multicast pour lui annoncer sa disponibilité. Un hôte reçoit des publications de routeur de la totalité des routeurs, constituant une liste des routeurs par défaut. Les routeurs génèrent des publications de routeur de façon suffisamment fréquente pour permettre aux hôtes d'être avertis de leur présence en quelques minutes. Cependant, les routeurs n'effectuent pas de publications à une fréquence suffisante pour se fier à une absence de publication permettant de détecter une défaillance de routeur. Un algorithme de détection séparé qui détermine l'inaccessibilité de voisin fournit la détection de défaillance.
Les publications de routeur contiennent une liste de préfixes de sous-réseau utilisés pour déterminer si un hôte se trouve sur le même lien que le routeur. La liste de préfixes est également utilisée pour la configuration d'adresses autonomes. Les indicateurs associés aux préfixes spécifient les utilisations spécifiques d'un préfixe particulier. Les hôtes utilisent les préfixes sur liaison publiés afin de constituer et de maintenir une liste utilisée pour décider lorsque la destination d'un paquet se trouve sur la liaison ou au-delà d'un routeur. Une destination peut se trouver sur une liaison même si celle-ci n'est couverte par aucun préfixe sur liaison publié. Dans de tels cas, un routeur peut envoyer une redirection. La redirection informe l'expéditeur que la destination est un voisin.
Les publications de routeur et les indicateurs par préfixe permettent aux routeurs d'informer des hôtes de la méthode qu'ils doivent utiliser pour effectuer une configuration automatique d'adresse sans état.
Les messages de publication de routeur contiennent également des paramètres Internet, comme la limite de saut, que les hôtes devraient utiliser dans des paquets entrants. Les messages de publication de routeur peuvent également (facultativement) contenir des paramètres de liens, comme le lien MTU. Cette fonctionnalité permet l'administration centralisée des paramètres critiques. Les paramètres peuvent être définis sur des routeurs et propagés automatiquement à tous les hôtes qui y sont connectés.
Les nœuds effectuent la résolution d'adresses par l'envoi de sollicitation de voisin à un groupe multicast, demandant au nœud cible de retourner son adresse de couche liaison. Les messages de sollicitation de voisin multicast sont envoyés à l'adresse de nœud multicast demandée de l'adresse cible. La cible retourne son adresse de couche liaison dans un message de publication d'un voisin unicast. Une paire de paquets de requête-réponse unique est suffisante pour permettre à l'initiateur et à la cible de résoudre les adresses de couche liaison de l'un et de l'autre. L'initiateur inclut son adresse de couche liaison dans la sollicitation de voisin.
Pour réduire toute dépendance possible d'un site IPv4/IPv6 double pile, il n'est pas nécessaire que tous les routeurs situés dans le chemin entre deux nœuds IPv6 soient compatibles avec IPv6. Le mécanisme prenant une telle configuration de réseau en charge s'appelle mise en tunnel. Les paquets IPv6 sont placés dans des paquets IPv4, qui sont ensuite acheminés via les routeurs IPv4. L'illustration suivante représente le mécanisme de mise en tunnel via des routeurs IPv4. Ces routeurs sont signalés sur l'illustration par un R.
L'implémentation du protocole IPv6 sous Oracle Solaris comprend deux types de mécanismes de mise en tunnel :
tunnels configurés entre deux routeurs, comme sur la Figure 11–5 ;
tunnels automatiques se terminant aux hôtes de points d'extrémité.
Un tunnel configuré est actuellement utilisé sur Internet à d'autres fins, par exemple, sur le MBONE, la dorsale multidiffusion IPv4. Fonctionnellement, le tunnel se compose de deux routeurs configurés de sorte à disposer d'une liaison virtuelle point à point entre les deux routeurs sur le réseau IPv4. Ce type de tunnel est susceptible d'être utilisé à l'avenir sur certaines parties d'Internet.
Les tunnels automatiques doivent disposer d'adresses compatibles avec IPv4. Les tunnels automatiques permettent de connecter des nœuds IPv6 en cas d'indisponibilité des routeurs IPv6. Ces tunnels peuvent provenir d'un hôte double pile ou d'un routeur double pile, grâce à la configuration d'une interface réseau de mise en tunnel automatique. Ces tunnels se terminent toujours sur l'hôte double pile. Ils déterminent de façon dynamique l'adresse IPv4 de destination, qui correspond au point d'extrémité du tunnel, en extrayant l'adresse à partir de l'adresse de destination compatible IPv4.
Le format des interfaces de création de tunnel est le suivant :
ip.tun ppa |
ppa correspond au point de connexion physique.
Lors du démarrage du système, le module de création de tunnel (tun) se place, via la commande ifconfig, sur l'IP afin de créer une interface virtuelle. Pour effectuer ce déplacement, vous devez créer le fichier hostname6.* adéquat.
Par exemple, pour créer un tunnel afin d'encapsuler les paquets IPv6 sur un réseau IPv4, IPv6 sur IPv4, créez le fichier suivant :
/etc/hostname6.ip.tun0 |
Le contenu de ce fichier est transféré à ifconfig une fois le montage des interfaces terminé. Le contenu correspond aux paramètres nécessaires pour configurer un tunnel point à point.
Vous trouverez ci-dessous un exemple d'entrées dans le fichier hostname6.ip.tun0 :
tsrc 10.10.10.23 tdst 172.16.7.19 up addif 2001:db8:3b4c:1:5678:5678::2 up |
Dans cet exemple, la source IPv4 et les adresses de destination sont utilisées comme des jetons afin de configurer automatiquement des adresses IPv6 lien-local. Ces adresses correspondent à la source et à la destination de l'interface ip.tun0. Deux interfaces sont configurées. L'interface ip.tun0 est configurée. Une interface logique, ip.tun0:1, est également configurée. Les adresses source et de destination IPv6 de l'interface logique sont spécifiées à l'aide de la commande addif.
Le contenu de ces fichiers de configuration est passé à ifconfig sans aucune modification lors du démarrage système en mode multiutilisateur. Les entrées de l'Exemple 11–11 sont équivalentes à ce qui suit :
# ifconfig ip.tun0 inet6 plumb # ifconfig ip.tun0 inet6 tsrc 10.0.0.23 tdst 172.16.7.19 up # ifconfig ip.tun0 inet6 addif 2001:db8:3b4c:1:5678:5678::2 up |
Vous trouverez ci-dessous la sortie de ifconfig -a pour ce tunnel.
ip.tun0: flags=2200850<UP,POINTOPOINT,RUNNING,MULTICAST, NONUD,IPv6> mtu 1480 index 6 inet tunnel src 10.0.0.23 tunnel dst 172.16.7.19 inet6 fe80::c0a8:6417/10 --> fe80::c0a8:713 ip.tun0:1: flags=2200850<UP,POINTOPOINT,RUNNING,MULTICAST,NONUD,IPv6> mtu 1480 index 5 inet6 2001:db8:3b4c:1:5678:5678::2 |
Vous pouvez configurer d'autres interfaces logiques en ajoutant des lignes au fichier de configuration à l'aide de la syntaxe suivante :
addif IPv6-source IPv6-destination up |
Lorsque l'une des extrémités du tunnel correspond à un routeur IPv6 qui publie un ou plusieurs préfixes sur le tunnel, il n'est pas nécessaire de disposer des commandes addif dans les fichiers de configuration de tunnel. Seul tsrc et tdst pourraient être nécessaires, car toutes les autres adresses sont configurées automatiquement.
Dans certains cas, les adresses lien-local source et de destination doivent être configurées manuellement pour un tunnel particulier. Modifiez la première ligne du fichier de configuration afin d'inclure ces adresses lien-local. La ligne suivante est un exemple :
tsrc 10.0.0.23 tdst 172.16.7.19 fe80::1/10 fe80::2 up |
Notez que l'adresse lien-local source dispose d'une longueur de préfixe de 10. Dans cet exemple, l'interface ip.tun0 ressemble à ce qui suit :
ip.tun0: flags=2200850<UP,POINTOPOINT,RUNNING,MULTICAST,NONUD,IPv6> mtu 1480 index 6 inet tunnel src 10.0.0.23 tunnel dst 172.16.7.19 inet6 fe80::1/10 --> fe80::2 |
Pour créer un tunnel afin d'encapsuler les paquets IPv6 sur un réseau IPv6, IPv6 sur IPv6, créez le fichier suivant :
/etc/hostname6.ip6.tun0 |
L'exemple suivant correspond à des entrées du fichier hostname6.ip6.tun0 pour une encapsulation IPv6 sur un réseau IPv6 :
tsrc 2001:db8:3b4c:114:a00:20ff:fe72:668c tdst 2001:db8:15fa:25:a00:20ff:fe9b:a1c3 fe80::4 fe80::61 up |
Pour créer un tunnel afin d'encapsuler les paquets IPv4 sur un réseau IPv6, IPv4 sur IPv6, créez le fichier suivant :
/etc/hostname.ip6.tun0 |
L'exemple suivant correspond à des entrées du fichier hostname.ip6.tun0 pour une encapsulation IPv4 sur un réseau IPv6 :
tsrc 2001:db8:3b4c:114:a00:20ff:fe72:668c tdst 2001:db8:15fa:25:a00:20ff:fe9b:a1c3 10.0.0.4 10.0.0.61 up |
Pour créer un tunnel afin d'encapsuler les paquets IPv4 sur un réseau IPv4, IPv4 sur IPv4, créez le nom de fichier suivant :
/etc/hostname.ip.tun0 |
L'exemple suivant correspond à des entrées du fichier hostname.ip.tun0 pour une encapsulation IPv4 sur un réseau IPv4 :
tsrc 172.16.86.158 tdst 192.168.86.122 10.0.0.4 10.0.0.61 up |
Pour obtenir des informations spécifiques sur tun, reportez-vous à la page de manuel tun(7M). Pour obtenir une description générale des concepts de création de tunnel lors de la transition vers le protocole IPv6, reportez-vous à la section Présentation des tunnels IPv6. Pour obtenir une description des procédures de configuration de tunnels, reportez-vous à la section Tâches de configuration de tunnels pour la prise en charge d'IPv6 (liste des tâches).
Dans Oracle Solaris, la création de tunnels 6to4 constitue la méthode temporaire recommandée pour effectuer la transition entre les adressages IPv4 et IPv6. Les tunnels 6to4 permettent aux sites IPv6 isolés de communiquer, par le biais d'un tunnel automatique, avec un réseau IPv4 ne prenant pas en charge le protocole IPv6. Pour utiliser des tunnels 6to4, vous devez configurer un routeur de bordure sur le réseau IPv6 en tant que point d'extrémité du tunnel 6to4 automatique. Par la suite, le routeur 6to4 peut participer à un tunnel vers un autre site 6to4 ou vers un site IPv6 natif et non-6to4, le cas échéant.
Cette section fournit des références sur les rubriques concernant les tunnels 6to4 :
Topologie d'un tunnel 6to4
Adressage 6to4 (et format de publication)
Description du flux de paquets dans un tunnel 6to4
Topologie d'un tunnel reliant un routeur 6to4 et un routeur relais 6to4
Informations importantes pour la configuration de la prise en charge d'un routeur relais 6to4
Le tableau suivant décrit les autres tâches permettant de configurer des tunnels 6to4 et les ressources permettant obtenir d'autres informations utiles.
Tâche ou détail |
Référence |
---|---|
Configuration d'un tunnel 6to4 | |
RFC lié aux 6to4 | |
Informations détaillées sur la commande 6to4relay (prise en charge des tunnels vers un routeur relais 6to4) | |
Problèmes de sécurité avec 6to4 |
Un tunnel 6to4 offre la connexion IPv6 à tous les sites 6to4, quel que soit leur emplacement. De même, le tunnel offre un lien à l'ensemble des sites IPv6, notamment l'Internet IPv6 natif, à condition d'être configuré pour la transmission vers un routeur relais. La figure suivante illustre un tunnel 6to4 connectant des sites 6to4.
La figure illustre deux réseaux 6to4 isolés (Site A et Site B). Chaque site possède un routeur configuré avec une connexion externe à un réseau IPv4. Un tunnel 6to4 à l'échelle du réseau IPv4 offre une connexion entre sites 6to4.
Pour convertir un site IPv6 en site 6to4, vous devez configurer au moins une interface de routeur prenant en charge 6to4. Cette interface doit assurer la connexion externe au réseau IPv4. L'adresse que vous configurez sur qfe0 doit être globale et unique. Sur cette figure, l'interface du routeur A (qfe0) connecte le site A au réseau IPv4. L'interface qfe0 doit déjà être configurée avec une adresse IPv4 pour que vous puissiez définir qfe0 en tant que pseudointerface 6to4.
Dans cet exemple, le site A 6to4 se compose de deux sous-réseaux connectés aux interfaces hme0 et hme1 du routeur A. Dès que les hôtes IPv6 des sous-réseaux du site A reçoivent la publication du routeur A, ils sont automatiquement reconfigurés sur les adresses 6to4 dérivées.
Le site B est un autre site 6to4 isolé. Pour recevoir correctement le trafic du site A, un routeur de bordure sur le site B doit être configuré pour prendre en charge 6to4. Dans le cas contraire, le routeur ne reconnaît pas les paquets reçus du site A et les abandonne.
Cette section décrit le flux de paquets allant d'un hôte sur un site 6to4 à un autre hôte sur un site 6to4 distant. Ce scénario nécessite la topologie illustrée sur la Figure 11–6. Cela suppose également de configurer au préalable les routeurs et les hôtes 6to4.
Un hôte du sous-réseau 1 appartenant au site 6to4 A envoie une transmission à un hôte du site 6to4 B. Chaque en-tête de paquet possède des adresses 6to4 dérivées source et cible.
Le routeur du site A encapsule chaque paquet 6to4 dans un en-tête IPv4. Dans ce processus, le routeur définit l'adresse cible IPv4 de l'en-tête d'encapsulation sur l'adresse du routeur du site B. L'adresse cible IPv6 de chaque paquet IPv6 transmis via l'interface du tunnel contient également l'adresse cible IPv4. Ainsi, le routeur est en mesure de déterminer l'adresse cible IPv4 définie sur l'en-tête d'encapsulation. Ensuite, il utilise la procédure de routage IPv4 standard pour transmettre le paquet sur le réseau IPv4.
Tout routeur IPv4 rencontré par les paquets utilise l'adresse IPv4 cible de ces derniers pour la transmission. Cette adresse constitue l'adresse IPv4 globale et unique de l'interface du routeur B, qui sert également de pseudointerface 6to4.
Les paquets du site A arrivent sur le routeur B qui les décapsule en paquets IPv6 à partir de l'en-tête IPv4.
Le routeur B se sert alors de l'adresse cible des paquets IPv6 pour transmettre ces derniers à l'hôte destinataire sur le site B.
Les routeurs relais 6to4 fonctionnent en tant que points d'extrémité des tunnels reliant des routeurs 6to4 à des réseaux IPv6 natifs, non 6to4. Les routeurs relais constituent essentiellement des ponts entre le site 6to4 et les sites IPv6 natifs. Ce type de routeur risque de ne pas garantir la sécurité du réseau ; c'est pourquoi il n'est pas pris en charge par Oracle Solaris. Cependant, si votre site nécessite un tel tunnel, vous pouvez exécuter la commande 6to4relay pour créer le type de tunnel suivant.
Sur la Figure 11–7, le site A (6to4) doit communiquer avec un nœud du site B (IPv6 natif). L'illustration indique la trajectoire du trafic entre le site A et le site B à travers un tunnel 6to4 créé sur le réseau IPv4. Le tunnel dispose d'un routeur A 6to4 et d'un routeur relais 6to4 à chaque extrémité. Au-delà du routeur 6to4 se trouve le réseau IPv6 auquel le site B IPv6 est connecté.
Cette section décrit le flux de paquets se déplaçant d'un site 6to4 vers un site IPv6 natif. Ce scénario nécessite la topologie illustrée sur la Figure 11–7.
Un hôte résidant sur le site A (6to4) envoie une transmission à un hôte de destination appartenant au site B (IPv6 natif). Chaque en-tête de paquet possède une adresse 6to4 dérivée en tant qu'adresse source. L'adresse de destination correspond à une adresse IPv6 standard.
Le routeur 6to4 du site A encapsule chaque paquet dans un en-tête IPv4, dont la destination correspond à l'adresse IPv4 du routeur relais 6to4. Ensuite, il utilise la procédure de routage IPv4 standard pour transmettre le paquet sur le réseau IPv4. Tout routeur IPv4 rencontré par les paquets envoie ceux-ci vers le routeur relais 6to4.
Le routeur relais 6to4 anycast le plus proche (physiquement) du site A récupère les paquets destinés au groupe anycast 192.88.99.1.
Les routeurs relais 6to4 faisant partie du groupe anycast de routeurs relais 6to4 possèdent l'adresse IP 192.88.99.1. Cette adresse anycast constitue l'adresse par défaut des routeurs relais 6to4. Si vous avez besoin d'un routeur relais 6to4 spécifique, vous pouvez supprimer celui par défaut et spécifier l'adresse IPv4 du routeur en question.
Ce routeur relais décapsule ensuite l'en-tête IPv4 des paquets 6to4, dévoilant l'adresse de destination sur le réseau IPv6.
Finalement, il envoie ces paquets IPv6 sur le réseau IPv6, où un routeur du site B les récupère et les envoie au noeud IPv6 de destination.
Cette section décrit les modifications en matière d'attribution de noms introduites par l'implémentation d'IPv6. Vous pouvez stocker les adresses IPv6 dans les fichiers de services d'assignation de noms, NIS, LDAP, DNS ou ou tout autre fichier Oracle Solaris de votre choix. Vous pouvez également utiliser le protocole NIS à travers les transports RPC IPv6 pour la récupération de données NIS.
Un enregistrement de ressources spécifique IPv6, l'enregistrement de ressource AAAA, a été spécifié dans le document RFC 1886 DNS Extensions to Support IP Version 6. Cet enregistrement AAAA mappe un nom d'hôte en une adresse IPv6 de 128 bits. L'enregistrement PTR est toujours utilisé avec IPv6 pour mapper les adresses IP en noms d'hôtes. Les 32 quartets de d'adresse 128 bits sont inversés pour une adresse IPv6. Chaque quartet est converti dans sa valeur hexadécimale ASCII correspondante. Ensuite, ip6.int est joint.
Pour Solaris 10 11/06 et versions antérieures, en plus de la capacité de recherche d'adresses IPv6 via /etc/inet/ipnodes , la prise en charge IPv6 a été ajoutée aux services d'attribution de noms NIS, LDAP et DNS. Par conséquent, le fichier nsswitch.conf a été modifié afin de prendre les recherches IPv6 en charge.
hosts: files dns nisplus [NOTFOUND=return] ipnodes: files dns nisplus [NOTFOUND=return] |
Avant de modifier le fichier /etc/nsswitch.conf pour rechercher ipnodes dans plusieurs services d'attribution de noms, renseignez ces bases de données ipnodes avec des adresses IPv4 et IPv6. Autrement, des retards inutiles peuvent entraîner une résolution des adresses hôtes, notamment des retards de durée d'initialisation.
Le diagramme suivant illustre la nouvelle relation entre le fichier nsswitch.conf et les nouvelles bases de données de services d'attribution de noms utilisant les commandes gethostbyname et getipnodebyname. Les nouveaux éléments sont en italique. La commande gethostbyname vérifie uniquement les adresses IPv4 stockées dans /etc/inet/hosts. Dans Solaris 10 11/06 et versions antérieures, la commande getipnodebyname consulte la base de données spécifiée dans l'entrée ipnodes du fichier nsswitch.conf. En cas d'échec de la recherche, la commande vérifie la base de données spécifiée dans l'entrée hosts du fichier nsswitch.conf.
Pour plus d'informations sur les services de noms, reportez-vous au document System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP) .
Pour la prise en charge d'IPv6, vous pouvez rechercher les adresses IPv6 avec les commandes existantes des services d'attribution de noms. Par exemple, la commande ypmatch fonctionne avec les nouveaux mappages NIS. La commande nslookup peut rechercher les nouveaux enregistrements AAAA dans DNS.
Les logiciels NFS et RPC (Remote Procedure Call, appel de procédure distant) prennent IPv6 en charge de façon totalement fluide. Les commandes existantes relatives aux services NFS restent inchangées. Il est également possible d'exécuter la plupart des applications RPC sur IPv6 sans aucune modification. Certaines applications RPC avancées de reconnaissance d'acheminement peuvent nécessiter une mise à jour.
Oracle Solaris prend en charge le protocole IPv6 sur des ATM, des PVC (Permanent Virtual Circuits, circuits virtuels permanents) et des SVC (Switched Virtual Circuits, circuits virtuels à commutation) statiques.