En Une :

Neighbor Discovery (ND) et l'autoconfiguration

En IPv6, ICMPv6 devient une composante obligatoire. Neighbor Discovery est un sous-protocole ICMPv6 (types 133 à 137). Il remplit notamment les fonctions de résolution d’adresses (ARP en IPv4) qui sont désormais appelées fonction de découverte de voisins. On ne parle plus de table ARP mais de table de voisinage. Il participe au mécanisme d'autoconfiguration automatique sans état (SLAAC).

Les routeurs configurent automatiquement l’adressage par des "Router Advertisments" autonomes ou sollicités par des Router Solicitation (Messages ND type 133/134).

Les routeurs ne fragmentant plus le trafic, cette fonction est laissée obligatoirement aux hôtes. Ils utilisent des paquets ICMPv6 Packet Too Big (Type 2).

1. ICMPv6 et IPv6

IPv6 et ICMPv6 sont inter-dépendants.

Leur fonctionnement permet leur autonomie en communication locale, sans état, et une communication indépendante de la nature de l'infrastructure.

IPv6 est par ailleurs supporté par un grand nombre de technologies de couche 2 Liaison de Données (L2).

  • ICMPv6 est un nouveau protocole formalisé par le RFC 4443.
  • Messages d’erreur : Destination Unreachable, Packet Too Big, Time Exceeded, et Parameters Problems.
  • Messages informatifs : messages de diagnostic (echos), messages pour la gestion des groupes multicast, et messages de découverte de voisinage ND (RFC 4861) et SEND (RFC 3971).

2. Neighbor Discovery

En IPv6, l’usage d’ARP disparaît (comme celui du broadcast). C’est ND (Neighbor Discovery) qui reprend cette fonction.

ND est encapsulé dans des paquets ICMPv6 eux-mêmes encapsulés dans de un en-tête IPv6.

En ce sens, pour cette fonction, IPv6 se suffit à lui-même, contrairement à IPv4.

ND embarque des fonctions nouvelles (NUD, DAD, SLAAC, validité des adresses) et d’autres messages d’un type nouveau (NS/NA, RA/RS).

2.1. Cinq types de messages ICMPv6 ND

Type Dénomination
1. Type ICMPv6 133 Router Solicitation (RS)
2. Type ICMPv6 134 Router Advertisement (RA)
3. Type ICMPv6 135 Neighbor Solicitation (NS)
4. Type ICMPv6 136 Neighbor Advertisement (NA)
5. Type ICMPv6 137 Redirect

On s'intéressera ici uniquement aux échanges NS/NA dans le cadre de la découverte et du maintien des relations de voisinages IPv6 et dans le cadre du mécanisme d’autoconfiguration.

2.2. Mécanismes ND

  • Address Autoconfiguration : assignation automatique d'adresse sans état,
  • Address Resolution : établissement de la correspondance entre adresse IP et adresse MAC,
  • Next-hop Determination : détermination du routeur pour une destination spécifique,
  • Neighbor Unreachability Detection : détermine qu'un hôte n'est plus accessible,
  • Duplicate Address Detection : détermine si un autre hôte utilise la même adresse IP,
  • Router Discovery : les hôtes peuvent détecter les routeurs sur les liens auxquels ils sont connectés,
  • Prefix Discovery : les hôtes peuvent découvrir les préfixes sur les liens,
  • Parameter Discovery : découverte de paramètres comme le MTU, le serveur DNS, NTP, SIP, etc.
  • Redirect : information qu'un autre routeur sur le lien fournit un meilleur next hop.

2.3. Découverte et maintien de voisinage IPv6

Des nouveaux messages ICMPv6 embarquent des fonctions de découverte de voisinage :

  1. Neighbor Solicitation, NS : destination en Solicited-Node Multicast ou en Unicast
  2. Neighbor Advertisment, NA : destination en Unicast ou All-nodes Multicast (FF02::1)

Les noeuds IPv6 maintiennent des tables de voisinage à l'instar de la table ARP en IPv4 grâce à de nouveaux mécanismes comme DAD et NUD .

Voici un exemple d’échange NA/NS : https://www.cloudshark.org/captures/905d563decac.

2.4. Résolution d’adresse

Découverte de voisinage sollicitée :

2.5. Adresse Solicited-Node Multicast

Une adresse Solicited-Node Multicast est jointe en destination dans des messages NS de découverte de voisin.

Cette adresse est construite :

  • en prenant les 24 dernier bits de l'adresse IPv6 connue (unicast)
  • et en lui ajoutant le préfixe ff02:0:0:0:0:1:ff00::/104

Par exemple

  • fc00::1/64 sera joint par f02::1:ff00:1.
  • fe80::2aa:ff:fe28:9c5a sera joint par ff02::1:ff28:9c5a.

Un hôte doit joindre une adresse Solicited-Node multicast pour chaque adresses unicast ou anycast configurée.

Ce mécanisme remplace le Broadcast d’ARP.

2.6. Diagnostic ND

Table de voisinage (sous Windows) : netsh interface ipv6 show neighbors
Voyez les inscriptions aux groupes multicast : netsh interface ipv6 show joins

Captures SLAAC, trafic DAD, trafic NUD : https://www.cloudshark.org/captures/f8773b94180f

2.7. Commandes ND

OS Voir le cache ND Effacer une entrée Vider le cache ND
FreeBSD ndp -a ndp -d ndp -c
IOS show ipv6 neighbors - clear ipv6 neighbors
JunOS show ipv6 neighbors - clear ipv6 neighbors
Linux ip -6 neigh show - ip -6 neigh flush
Mac OS X ndp -a ndp -d ndp -c
Vyatta show ipv6 neighbors - clear ipv6 neighbors
Windows netsh interface ipv6 show neighbors - netsh interface ipv6 delete neighbors

3. Router Advertisement

3.1. Le routeur configure le réseau

Une nouveauté d’IPv6 parmi d’autres sont les échanges Neighbor Discovery (ND) “Router Solicitation” (RS ICMPv6 type 133) et “Router Advertisement” (RA ICMPv6 type 134).

Ces paquets configurent le réseau en fournissant sur demande ou en annonce gratuite les paramètres de configuration des interfaces.

3.2. Paramètres RA

Les Router Advertisements sont des messages ICMPv6 type 134 disposant d’un en-tête IPv6 et d’un en-tête de couche 2 (Ethernet par exemple).

Ces paquets contiennent principalement, a priori,

  1. un champ de drapeaux (Flags) qui indique l’usage de DHCP stateful et/ou stateless
  • et une valeur de préférence de routeur,
  • des options :
    • Un préfixe avec son masque
    • Le MTU que l’interface doit prendre
    • L’adresse source de couche 2 du message
    • Éventuellement, l’adresse d’un serveur DNS récursif, un cache (RDNSS). Cette option est peu supportée.

3.3. Router Advertisements

  • Type 134, code 0
  • Drapeaux M, O, Prf
  • Options : MTU, adresse source L2 et préfixe
  • L’adresse source du message DOIT être l’adresse Link-Local de l’interface qui envoie le message
  • L’adresse de destination est habituellement l’adresse source du routeur sollicité (Router Solicitation) ou l’adresse All-Nodes Multicast (FF02::1)

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |     Code      |          Checksum             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Cur Hop Limit |M|O|H|Prf|Resvd|       Router Lifetime         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Reachable Time                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Retrans Timer                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Options ...
      +-+-+-+-+-+-+-+-+-+-+-+-

RFC4191 màj Neighbor Discovery RFC 4861 Section 4.2 et RFC 6275 Section 7.1

3.4. RA : Flags et Options

Ethernet II, Src: Globalsc_01:df:95 (f0:ad:4e:01:df:95), Dst: IPv6mcast_00:00:00:01 (33:33:00:00:00:01)
Internet Protocol Version 6, Src: fe80::f2ad:4eff:fe01:df95 (fe80::f2ad:4eff:fe01:df95), Dst: ff02::1 (ff02::1)
Internet Control Message Protocol v6
    Type: Router Advertisement (134)
    Code: 0
    Checksum: 0x1bc0 [correct]
    Cur hop limit: 64
    Flags: 0xc0
    Router lifetime (s): 1800
    Reachable time (ms): 0
    Retrans timer (ms): 0
    ICMPv6 Option (Prefix information : 2001:db8:ffff::/64)
    ICMPv6 Option (MTU : 1500)
    ICMPv6 Option (Source link-layer address : f0:ad:4e:01:df:95)
    ICMPv6 Option (Recursive DNS Server fe80::f2ad:4eff:fe01:df95)

3.5. Quatre méthodes de configuration IPv6

Ces quatre méthodes peuvent se combiner au choix et servir à la gestion de l’adressage IPv6 ainsi qu’à la re-numérotation IPv6. Elles sont indiquées dans le champ Flags :

  • Managed address configuration: Flag M : DHCPv6 Stateful assignation d’adresse dynamique
  • Other configuration : Flag O :DHCPv6 Stateless demande d’options supplémentaires
  • Home Agent: Mobilité IPv6
  • Prf (Default Router Preference): valorisation du RA par rapport à un autre (3 valeurs, 2 bits)
  • Reserved: Pour un usage futur
Configuration Flag M Flag O
1) Configuration statique 0
2) Stateless Automatic Autoconfiguration (SLAAC) seul 0
3) DHCPv6 (Stateful) 1
4) DHCPv6 Stateless 0

3.6. Option Prefix Information

L’option Prefix Information liste chaque préfixe IPv6 annoncé avec une série d’informations :

  • Le drapeau “L” "on-link" (OnLinkFlag).
  • La valeur de durée de vie de validité
  • Le drapeau “A” "Autonomous address configuration" qui indique que l’interface utilise SLAAC avec ce préfixe.
  • La valeur de durée de vie de préférée

3.7. Exemple Option Type 3

Quelle que soit la position du drapeau M ou O, ce sont les champs L et A qui indiquent l’usage de l’autoconfiguration automatique sans état (SLAAC).

Cela signifie qu’une interface pourrait disposer pour chaque préfixe annoncé d’une adresse attribuée par DHCPv6 et une ou plusieurs adresses SLAAC.

ICMPv6 Option (Prefix information : 2001:db8:ffff::/64)
        Type: Prefix information (3)
        Length: 4 (32 bytes)
        Prefix Length: 64
        Flag: 0xc0
            1... .... = On-link flag(L): Set
            .1.. .... = Autonomous address-configuration flag(A): Set
            ..0. .... = Router address flag(R): Not set
            ...0 0000 = Reserved: 0
        Valid Lifetime: 3600
        Preferred Lifetime: 3600
        Reserved
        Prefix: 2001:db8:ffff:: (2001:db8:ffff::)

3.8. Scénarios RA

Flags :

SLAAC Autonomous (option Prefix Information) Managed Configuration Address ManagedFlag Other Configuration OtherConfigFlag Scénario
1 SLAAC 1 0 0
2 Stateless DHCPv6 1 0 1
3 Statefull DHCPv6 0 1 1
4 Statefull DHCPv6 + SLAAC 1 1 1

Le champ Prf donne une préférence au routeur codée sur 2 bits : 01(High), 00 (Medium par default), 11 (Low).

4. Auto-configuration sans état (SLAAC)

L’auto-configuration sans état est formalisée dans le RFC 4862.

4.1. Autoconfiguration

  • Toute interface activée en IPv6 génère une adresse Lien Local.
  • Si un routeur est activé en IPv6, l'interface se configure automatiquement avec une ou plusieurs adresses globales ou privées (par défaut)
  • L'interface vérifie chaque adresse automatique avant de l'utiliser (DAD) et vérifie régulièrement l'existence de ses voisins (NUD).

4.2. Sans état

  • Pas de maintien de relations (non fiable, non orienté-connexion).
  • La charge est placée sur les noeuds
  • Mode crédule
  • Importance du filtrage L2/L3

4.3. DAD (Duplicate Address Detection)

DAD (Duplicate Address Detection) est un mécanisme qui permet vérifier l’unicité d’une adresse auto-configurée sur un réseau.

Dans cette procédure, l’interface IPv6 va envoyer un NS (Neighbor Solicitation) à destination de l’adresse solicited-node multicast correspondant à son adresse de tentative. L’adresse source est non spécifiée (::/128). En cas de réponse (NA), l’adresse n’est pas unique !

Dans cet exemple, http://www.cloudshark.org/captures/0423a2ed75a8, une interface Windows qui démarre génère trois NS. Veuillez examiner :

  • L’adresse IP source
  • L’adresse IP destination
  • L’adresse IP contenue dans la charge

Pourquoi trois paquets dans ce cas ?

No Source Destination        Info
1  ::     ff02::1:ff7e:4a1e  NS for fe80::1816:c126:507e:4a1e
2  ::     ff02::1:ff7e:4a1e  NS for 2001:470:cbf7:1ab:1816:c126:507e:4a1e
3  ::     ff02::1:ff0c:66ce  NS for 2001:470:cbf7:1ab:83c:9e7e:2f0c:66ce

4.4. NUD (Neighbor Unreachability Detection)

NUD (Neighbor Unreachability Detection) est un algorithme défini dans le RFC4861 qui met en jeu des échanges NS/NA et leur délai.

NUD définit 5 états du cache de voisinage parmi lesquels :

  • Incomplete : la résolution d’adresse est en train de se dérouler. Un NS vers une adresse solicited-node multicast est envoyé mais le NA de retour correspondant n’est toujours pas arrivé.
  • Reachable : Une confirmation positive a été reçue. L’hôte de destination est joignable dans le délai “ReachableTime milliseconds”.
  • Stale : L’hôte de destination n’est pas joignable dans le délai “ReachableTime milliseconds”. Entre dans cet état lors d’un message NA non sollicité.
  • Delay et Probe.

4.5. Durée de vie des adresses

Les adresses IPv6 associées à une interface ont une durée de vie déterminée. La durée de vie est en général infinie, mais on peut configurer :

  • une durée de vie préférée
  • et une durée de vie de validité.

Ces durées de vie sont configurées dans les routeurs qui fournissent les préfixes pour la configuration automatique (RA, Router Advertisement).

En combinaison avec un changement DNS correspondant, ces durées de vie permettent une transition progressive vers une nouvelle adresse IPv6 (appartenant à un nouveau fournisseur de service par exemple) sans interruption de service.

Quand la durée d'utilisation d'une adresse dépasse la durée préférée, elle n'est plus utilisée pour les nouvelles connexions. Quand sa période de validité est atteinte, elle est supprimée de la configuration de l'interface.

4.6. Dépréciation d’une adresse

En effet, une interface pourrait recevoir du trafic entre sa durée préférée et son invalidité.

Source de l'image : http://livre.g6.asso.fr/index.php/Protocole_de_Découverte_des_voisins#Cycle_de_vie_d.27une_adresse

4.7. La sélection d’adresses

Le RFC 6274 fournit deux algorithmes à suivre pour que la sélection d'adresse source et destination par défaut soit prévisible.

C’est utile quand une interface (source) dispose de plus d’une adresse IPv6, ce qui ne sera pas rare.
Quid quand la destination dispose d’une adresse IPv4 et d’une IPv6 (AAAA) ? Ce RFC remplace le RFC 3484.

Une adresse IPv6 est préférée à une adresse IPv4.

Si on veut résumer les deux algorithmes utilisés, on peut dire qu'ils préfèrent former des couples source/destination où les deux adresses ont

  • la même portée,
  • ont la portée la plus étroite possible,
  • sont des adresses préservant la vie privée (ULA),
  • et, en fin de compte, partagent le plus de bits de préfixe possibles.

Source : Bortzmeyer)

4.8. Happy Eyeballs

“Happy Eyeballs” est une algorithme proposé par le RFC 6555 afin de rendre l’expérience utilisateur dual-stack IPv4/IPv6 plus fluide.

Une application “Happy Eyeballs” choisit le protocole qui répond le premier suite à un test de connectivité.
Cet algorithme est disponible dans les navigateurs Google Chrome, Opera 12.10, Firefox version 13, and Mac OS X Lion. (Wikipedia)

4.9. Mécanisme SLAAC

L'autoconfiguration sans état, Stateless Automatic Auto Configuration (SLAAC) :

  • Méthode par défaut dans un environnement routé pour les routeurs et les noeuds.
  • Le routeur (RAs) donne toute une série de paramètres :
    • préfixe(s) avec le Flag A activé, mtu, préférence, passerelle, Flags M et O
  • L'interface construit elle-même son identifiant d'interface selon différentes méthodes
    • MAC EUI 64
    • de manière aléatoire

4.10. Illustration du mécanisme SLAAC

  1. Toute interface activée en IPv6 génère une adresse Lien Local avec le préfixe FE80::/10 suivi d'un identifiant d'interface.
  • Elle vérifie l'existence de l'adresse générée via un mécanisme appelé DAD (Duplicate Address Detection).
  • Sans réponse, elle peut utiliser cette adresse sur le lien local.
  • Elle sollicite un routeur en Multicast.
  • S'il est présent sur le réseau, le routeur IPv6 répond avec des paramètres de configuration RA et Options.
  • L'interface élabore son ou ses adresses selon ce qu'indique le routeur. Elle installe sa passerelle par défaut.
  • Régulièrement, l'interface va vérifier l'existence des noeuds voisins appris par processus ND (NUD).

slaac

4.11. SLAAC : adresses générées

Avec des RA dont les drapeaux sont placés M=1, O=1, L=1 et A=1 (sur le préfixe), cette interface pourra prendre quatre adresses, soit une DHCPv6, deux SLAAC et une Link-Local :

... (à compléter)

et ses trois groupes Multicast joints

... (à compléter)

Author image
Francois Goffinet est formateur Cisco Systems depuis 2002. Passionné des technologies des réseaux, de virtualisation et en nuage, Web et de cybersécurité souvent en Open Source ou Unix-Like, devops.