Il est défini trois grand groupes d'adresses:
Dans les adresses «unicast», nous verrons les adresses de type:
Le type que nous étudierons particulièrement est le type unicast celui qui est utilisé lorsque deux partenaires veulent communiquer entre eux.
Avec IPv4, nous avons vu que le procédé le plus efficace pour configurer les nœuds d'un réseau local consiste à faire appel à un serveur DHCP. Nous en avons rapidement mis un en œuvre, mais pour le grand public, les diverses «box» proposées par les F.A.I embarquent cette fonctionnalité.
Avec IPv6, le moyen le plus simple est l'auto-configuration appelé «stateless» (sans état), c'est ce qui est retenu lorsque le F.A.I propose des adresses IPv6 à ses clients. Votre serviteur étant un abonné de très longue date chez Free, nous ne pourrons considérer que ce que ce F.A.I propose.
Notons tout de suite que la configuration manuelle reste utile dans certains cas particuliers, de même que DHCP existe toujours en IPv6. Dans ce contexte, l'adresse est alors dite «stateful».
Alors qu'en IPv4, la «box» récupère côté internet une et une seule adresse IP publique, qu'elle fournit des configurations IPv4 aux nœuds du LAN avec des adresses IPv4 privées et assure le «masquerade» entre le LAN et l'internet, en IPv6, elle va transmettre aux nœuds du LAN un préfixe de 64 bits et les interfaces dans les nœuds du LAN vont se calculer leur propre jeton, c'est-à-dire les 64 bits de poids le plus faible de leur(s) adresse(s) IPv6 en s'inspirant de leur adresse MAC, réputée unique sur le LAN, ce qui s'appelle l'«IPv6 Stateless Address Auto-configuration (SLAAC)».
Les petits malins vont me dire «oui, mais une adresse MAC ne fait que 48 bits (6 octets), il va en manquer 16… et ils auront raison, mais les concepteurs d'IPv6 y ont pensé (ils sont malins), alors voici comment ils règlent la question:
L'intégration d'une constante entre les deux membres de l'adresse MAC donne toujours une valeur unique dans le LAN et les 64 bits sont bien présents dans le jeton. L'IEEE a défini cette façon de faire sous l’appellation EUI-64 (Extended Unique Identifier 64 bits).
Un petit utilitaire que l'on peut installer sur toute bonne distribution GNU/Linux permet de calculer et d'afficher proprement le résultat. Il se nomme ipv6calc
.
Soir une interface Ethernet ayant l'adresse MAC 52:54:00:56:52:92
. En utilisant ipv6calc de la façon suivante:
ipv6calc --action geneui64 --in mac --out eui64 52:54:00:56:52:92 5054:ff:fe56:5292Si l'on écrit ce jeton sous sa forme étendue:
5054:00ff:fe56:5292Nous retrouvons bien la structure décrite plus haut. Nous disposons désormais du jeton attaché à cette interface
Si IPv6 est activé sue le nœud disposant de cette interface, nous pouvons alors observer ceci :
ip -6 addr ls enp1s0 2: enp1s0:Nous trouvons deux adresses v6:mtu 1500 qdisc fq_codel state UP group default qlen 1000 inet6 2a01:e0a:875:b1d0:5054:ff:fe56:5292/64 scope global dynamic mngtmpaddr valid_lft 86262sec preferred_lft 86262sec inet6 fe80::5054:ff:fe56:5292/64 scope link valid_lft forever preferred_lft forever
L'outil whois
est bien utile pour découvrir quelques informations:
whois 2a01:e0a:875:b1d0:5054:ff:fe56:5292 inet6num: 2a01:e00::/26 netname: FR-PROXAD-20080121 country: FR org: ORG-PISP1-RIPE admin-c: ACP23-RIPE tech-c: TCP8-RIPE status: ALLOCATED-BY-RIR mnt-by: RIPE-NCC-HM-MNT mnt-by: PROXAD-MNT mnt-routes: PROXAD-MNT mnt-domains: PROXAD-MNT created: 2008-01-21T14:17:01Z last-modified: 2018-02-14T01:51:58Z source: RIPE # FilteredNous découvrons que le réseau
2a01:e00::/26
a été «ALLOCATED-BY-RIR1)» à PROXAD (Free SAS).
Le préfixe reçu est donc bien dans le réseau Proxad.
Les plus curieux pourront consulter https://stat.ripe.net/ pour vérifier la visibilité du préfixe du FAI.
fe80::
identique sur tous les LANs. Pour une interface donnée, le jeton reste le même. ce que nous avons pu constater plus haut.
L'utilité d'une telle adresse apparaîtra plus clairement dans la suite.
Décrites dans la RFC4193, les ULA (Unique Local Addresses) , dont le préfixe est fd00::/8
c'est un peu comme les plages d'adresses IPv4 privées.
Elles sont destinées à un usage interne au sein du réseau privé d'une organisation et ne sont pas destinées à être routables globalement sur l'Internet public.
Les ULA commencent par 4 octets allant de fd00
à fdff
.
Pour éviter d'éventuels conflits, il est recommandé de générer la partie sous-réseau de l'ULA à l'aide d'un générateur de nombres aléatoires ou d'autres méthodes pour garantir l'unicité au sein de l'organisation.
Ces adresses sont routables, mais uniquement dans les sous-réseaux locaux. Autrement dit, elles ne le sont pas sur l'internet.
Un serveur DNS par exemple, qui disposerait d'une telle adresse, servit joignable depuis n'importe quel sous-réseau local, du moment que ces sous-réseaux disposent d'une passerelle par défaut, mais ne pourrait en aucun cas l'être depuis l'extérieur.
D'une manière générale, les ULA conviennent à l'attribution d'adresses aux composants d'infrastructure interne, tels que les routeurs, les commutateurs, les serveurs et d'autres périphériques et nous aurons l'occasion d'expérimenter ceci dans la suite.
Lorsqu'un nœud démarre, nous savons qu'avec IPv4 il va généralement commencer par rechercher un serveur DHCP pour obtenir sa configuration IP:
Avec IPv6, même si les adresses sont construites en mode «sans état», il faudra tout de même obtenir au minimum:
En IPv4 la séquence commençait par un broadcast ARP. En IPv6, le broadcast n'existe plus, remplacé par le multicast, ARP n'existe également plus, c'est ICMP qui prend le relais.
Les adresses multicast sont définies dans la RFC4291 et la RFC3306.
ff
;0
;
le «scope» définit la portée du groupe multicast.
Tout ceci étant bien compliqué, nous retiendrons pour l'instant que les adresses qui commencent par ff01::
ou ff02::
sont des adresses multicast.
Nous venons de mettre en évidence le NDP (Network Discovery Protocol) qui se résume dans notre étude à deux questions et à leur réponse: