Chapitre 11 Présentation détaillée de IPv6 (référence)

Ce chapitre contient des informations de référence concernant l'implémentation du protocole IPv6 sous Oracle Solaris 10.

• Notions approfondies sur les formats d'adressage IPv6

• Format d'en-tête de paquet IPv6

• Protocoles doubles piles

• Implémentation du protocole IPv6 sous Oracle Solaris 10

• Protocole ND IPv6

• Routage IPv6

• Tunnels IPv6

• Extensions IPv6 de services d'assignation de noms Oracle Solaris

• Prise en charge IPv6 de NFS et RPC

• Prise en charge d'IPv6 sur ATM

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

Nouveautés du chapitre Présentation détaillée de IPv6

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.

Notions approfondies sur les formats d'adressage IPv6

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 :

• Adresses 6to4 dérivées

• Présentation détaillée des adresses IPv6 multicast

Adresses 6to4 dérivées

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.

Figure 11–1 É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.

Figure 11–2 Éléments d'un préfixe de sous-réseau

Le tableau suivant explique les éléments constituant un préfixe de sous-réseau 6to4, les longueurs à respecter et leurs définitions.

Adresses 6to4 dérivées sur un hôte

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.

Présentation détaillée des adresses IPv6 multicast

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.

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.

Format d'en-tête de paquet IPv6

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.

Figure 11–3 Format d'en-tête IPv6 de base

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.

En-têtes d'extension IPv6

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

Protocoles doubles piles

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.

Figure 11–4 Architecture du protocole double pile

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.

Implémentation du protocole IPv6 sous Oracle Solaris 10

Cette section décrit les fichiers, commandes et démons nécessaires au protocole IPv6 sous Oracle Solaris.

Fichiers de configuration IPv6

Cette section décrit les fichiers de configuration faisant partie de l'implémentation IPv6 :

• Fichier de configuration ndpd.conf

• Fichier de configuration d'interface IPv6

• Fichier de configuration /etc/inet/ipaddrsel.conf

Fichier de configuration ndpd.conf

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.

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.

Le tableau suivant répertorie les variables utilisées pour configurer les préfixes IPv6.

Exemple 11–1 Fichier /etc/inet/ndpd.conf

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

Fichier de configuration d'interface IPv6

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

péri

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.

Module

Répertorie un ou plusieurs modules STREAMS à empiler sur le périphérique lorsque celui-ci est monté.

PPA

Indique le point d'attache physique.

La syntaxe [.[.]] est également acceptée.

Exemple 11–2 Fichiers de configuration d'interface IPv6

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

Fichier de configuration /etc/inet/ipaddrsel.conf

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

Commandes associées à IPv6

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.

Commande ipaddrsel

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

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.

Raisons pour lesquelles le tableau des règles de sélection d'adresses IPv6 doit être modifié

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

Commande 6to4relay

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.

Syntaxe de la commande 6to4relay

La commande 6to4relay possède la syntaxe suivante :

6to4relay -e [-a IPv4-address] -d -h

-e

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.

-a adresse IPv4

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

Désactive la prise en charge de tunnels vers un routeur relais 6to4 (paramètre par défaut de Oracle Solaris).

-h

Affiche l'aide concernant la commande 6to4relay.

Pour plus d'informations, reportez-vous à la page de manuel 6to4relay(1M).

Exemple 11–3 Affichage par défaut du statut de la prise en charge de routeurs relais 6to4

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

Exemple 11–4 Affichage du statut avec prise en charge des routeurs relais 6to4 activée

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

Exemple 11–5 Affichage du statut avec un routeur relais 6to4 spécifié

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.

Extensions de commande ifconfig pour la prise en charge IPv6

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.

index

Définit l'index de l'interface.

tsrc/tdst

Définit la source ou la destination du tunnel.

addif

Crée l'interface logique suivante.

removeif

Supprime une interface logique possédant une adresse IP spécifique.

destination

Définit l'adresse de destination point à point pour une interface.

set

Définit une adresse et/ou un masque de réseau pour une interface.

subnet

Définit l'adresse de sous-réseau d'une interface.

xmit/-xmit

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.

Exemple 11–6 Ajout d'une interface IPv6 logique avec l'option -addif de la commande ifconfig

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

Exemple 11–7 Suppression d'une interface IPv6 logique avec l'option -removeif de la commande ifconfig

La commande ifconfig suivante supprime une interface logique hme0:3 :

# ifconfig hme0:3 inet6 down

# ifconfig hme0 inet6 removeif 1234::5678

Exemple 11–8 Configuration de la source d'un tunnel IPv6 à l'aide de la commande ifconfig

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

Exemple 11–9 Configuration d'un tunnel 6to4 à l'aide de ifconfig (forme longue)

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 

Exemple 11–10 Configuration d'un tunnel 6to4 à l'aide de ifconfig (forme courte)

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 

Modification de la commande netstat en vue de la prise en charge IPv6

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.

Modification de la commande snoop en vue de la prise en charge IPv6

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.

Modification de la commande route en vue de la prise en charge IPv6

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

Modification de la commande ping en vue de la prise en charge IPv6

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 .

Modification de la commande traceroute en vue de la prise en charge IPv6

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.

Démons liés à IPv6

Cette section présente les démons liés à IPv6.

Démon in.ndpd pour Neighbor Discovery

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.

-d

Active le débogage.

-D

Active le débogage dans le cadre d'événements spécifiques.

-f

Spécifie un fichier de données de configuration spécifique au lieu du fichier /etc/inet/ndpd.conf.

-I

Imprime les informations associées à chaque interface.

-n

Ne met pas en boucle les publications du routeur.

-r

Ignore la réception de paquets.

-v

Spécifie le mode détaillé en faisant état de plusieurs types de message de diagnostic.

-t

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.

Démon in.ripngd, pour routage IPv6

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.

-p n

n spécifie le numéro de port alternatif utilisé pour l'envoi ou la réception de paquets RIPnG.

-q

Supprime les informations de routage.

-s

Force le routage d'informations même si le démon fait office de routeur.

-P

Supprime l'utilisation du poison reverse.

-S

Si in.ripngd n'agit pas en tant que routeur, le démon saisit uniquement une route par défaut pour chaque routeur.

Démon inetd et services IPv6

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.

Informations importantes relatives à la configuration d'un service pour IPv6

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.

Protocole ND IPv6

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 :

• Messages ICMP de la détection des voisins

• Processus de configuration automatique

• Sollicitation de voisin et inaccessibilité

• Algorithme de détection d'adresse dupliquée

• Comparaison du protocole ND et du protocole ARP et autres protocoles IPv4

Messages ICMP de la détection des voisins

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.

Processus de configuration automatique

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.

1. Une interface compatible multicast est activée, par exemple, lors du démarrage système d'un nœud.

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

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

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

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

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

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

Obtention d'une publication de routeur

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.

Variables de préfixes de configuration

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.

Unicité des adresses

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.

Sollicitation de voisin et inaccessibilité

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.

Algorithme de détection d'adresse dupliquée

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.

Publications de proxy

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.

Équilibrage de charge entrante

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.

Modification d'adresse lien-local

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.

Comparaison du protocole ND et du protocole ARP et autres protocoles IPv4

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.

Routage IPv6

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.

Publication de routeur

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.

Préfixes de publication de routeurs

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.

Messages de publication de routeurs

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.

Tunnels IPv6

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.

Figure 11–5 Mécanisme de mise en tunnel IPv6

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.

Tunnels configurés

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.

Exemple 11–11 Fichier hostname6.ip.tun0 pour un tunnel IPv6 sur IPv4

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

Exemple 11–12 Fichier hostname6.ip6.tun0 pour un tunnel IPv6 sur IPv6

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

Exemple 11–13 Fichier hostname.ip6.tun0 pour un tunnel IPv4 sur IPv6

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

Exemple 11–14 Fichier hostname.ip.tun0 pour un tunnel IPv4 sur IPv4

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

Tunnels automatiques 6to4

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.

Topologie d'un tunnel 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.

Figure 11–6 Tunnel entre deux 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.

Description du flux de paquets dans un tunnel 6to4

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.

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

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

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

4. Les paquets du site A arrivent sur le routeur B qui les décapsule en paquets IPv6 à partir de l'en-tête IPv4.

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

Informations importantes pour la création de tunnels vers un routeur relais 6to4

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.

Figure 11–7 Tunnel entre un site 6to4 et un routeur relais 6to4

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

Flux de paquets entre un site 6to4 et un site IPv6 natif

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.

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

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

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

   ---

   Remarque –

   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.

   ---

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

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

Extensions IPv6 de services d'assignation de noms Oracle Solaris

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.

Extensions DNS pour IPv6

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.

Modifications apportées au fichier nsswitch.conf

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.

Figure 11–8 Relation entre nsswitch.conf et les services d'attribution de noms

Pour plus d'informations sur les services de noms, reportez-vous au document System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP) .

Modifications apportées aux commandes de services d'attribution de noms

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.

Prise en charge IPv6 de NFS et RPC

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.

Prise en charge d'IPv6 sur ATM

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.