[IPv6-Tech] RFC 8064: Recommendation on Stable IPv6 Interface Identifiers

[Stephane Bortzmeyer]

Voilà, normalement, c'est fini de génerer des adresses IPv6 avec
l'adresse MAC dedans.

http://www.bortzmeyer.org/8064.html

----------------------------

Auteur(s) du RFC: F. Gont (SI6 Networks /
UTN-FRH), A. Cooper (Cisco), D. Thaler
(Microsoft), W. Liu (Huawei
Technologies)

Chemin des normes

----------------------------


Ce RFC parle de vie privée mais il est très court, car il se contente
de changer une règle, la nouvelle étant déjà largement acceptée.
Désormais, si une machine IPv6 configure son adresse par le système
SLAAC, et que cette adresse doit être stable dans le temps, désormais,
donc, la méthode recommandée est celle du RFC 7217 et non plus celle,
mauvaise pour la vie privée, d'utiliser l'adresse MAC. (Si l'adresse
n'a pas besoin d'être stable, aucun changement, la méthode recommandée
reste celle du RFC 4941, les adresses temporaires.)

Que veut dire SLAAC, au fait ? Ce mécanisme de configuration d'une
adresse IPv6 est normalisé dans le RFC 4862. L'idée est que la machine
écoute sur le réseau les annonces faites par les routeurs, apprenant
ainsi le·s préfixe·s IP du réseau. Elle ajoute ensuite à ce préfixe un
terme, l'identificateur d'interface (IID, cf. RFC 4291), formant ainsi
une adresse IPv6 mondiale, et unique (si l'IID est bien choisi). La
méthode originelle était de dériver l'IID de l'adresse MAC. Celle-ci
est en effet unique et, en prime, son utilisation présente certains
avantages (compression des en-têtes du RFC 6775, par exemple). Mais
s'en servir soulève plein de problèmes de sécurité et notamment de vie
privée : traçabilité des utilisateurs dans le temps, et dans l'espace
(si la machine se déplace, elle change de préfixe mais garde le même
identificateur d'interface), facilitation du balayage des adresses dans
le réseau, etc (cf. RFC 7721). D'une manière générale, réutiliser des
identificateurs d'un autre « monde » est une fausse bonne idée, souvent
dangereuse en matière de vie privée. Voilà pourquoi ce RFC dit
clairement que, désormais, il est fortement déconseillé d'utiliser les
adresses MAC. (Plusieurs mises en œuvre d'IPv6, comme celles de
Microsoft, avaient déjà cessé, avant même que ce RFC ne soit publié.)

Et ce RFC 7217 qu'il faut désormais suivre, il dit quoi ? Il propose de
fabriquer l'identificateur d'interface en condensat une concaténation
du préfixe et de diverses valeurs stables. Si on change de réseau, on a
une nouvelle adresse (on ne peut donc pas suivre à la trace une machine
mobile). Mais, si on reste sur le même réseau, l'adresse est stable.

La section 1 de notre RFC rappelle aussi la différence entre les
adresses stables et les autres. Toutes les adresses IP n'ont pas besoin
d'être stables. La solution la meilleure pour la vie privée est
certainement celle du RFC 4941, des adresses temporaires, non stables
(pour de telles adresses, on peut aussi utiliser le système des
adresses MAC si elles changent souvent par exemple avec macchanger
<https://www.it-connect.fr/changer-dadresse-mac-sous-linux-avec-macchang
er/>). Toutefois, dans certains cas, les adresses stables sont
souhaitables : l'administration réseaux est plus simple, les journaux
sont plus faciles à lire, on peut mettre des ACL, on peut avoir des
connexions TCP de longue durée, etc. Et, bien sûr, si la machine est un
serveur, ses adresses doivent être stables. Il y a donc une place pour
une solution différente de celle du RFC 4941, afin de fournir des
adresses stables. C'est seulement pour ces adresses stables que notre
RFC recommande désormais la solution du RFC 7217.

La nouvelle règle figure donc en section 3 de notre RFC : lorsqu'une
machine veut utiliser SLAAC *et* avoir des adresses stables, qui ne
changent pas dans le temps, tant que la machine reste sur le même
réseau, alors, dans ce cas et seulement dans ce cas, la méthode à
utiliser est celle du RFC 7217. L'ancienne méthode (qu'on trouve par
exemple dans le RFC 2464) d'ajouter le préfixe à l'adresse MAC ne doit
plus être utilisée.

Notez donc bien que ce RFC ne s'adresse pas à toutes les machines IPv6.
Ainsi, si vous configurez vos serveurs (qui ont clairement besoin d'une
adresse stable) à la main, avec des adresses en "leet" comme
2001:db8::bad:dcaf, ce RFC 8064 ne vous concerne *pas* (puisqu'il n'y a
pas de SLAAC).

Les RFC comme le RFC 4944, RFC 6282, RFC 6775 ou RFC 7428 devront donc
être remplacés par des documents tenant compte de la nouvelle règles.
(Cf. RFC 8065.)

Aujourd'hui, il semble que les dernières versions de Windows, iOS et
Android mettent déjà en œuvre la nouvelle règle.

[Bruno STEVANT]

Flute, il va falloir que l’on jette une partie des vidéos du MOOC IPv6 alors ?
En fait pas forcément, l’IID issu de l’adresse MAC va continuer à perdurer pour l’adresse lien local.
On aura donc, dans le cas général, 3 IID différents pour la même interface (1 local, 1 temporaire, 1 stable)
Du coup, est ce qu’il est toujours pertinent de désigner ces derniers 64bits comme identifiant d’*interface* ?

Cordialement,
--
Bruno STEVANT - IMT Atlantique

Post by Stephane Bortzmeyer
Voilà, normalement, c'est fini de génerer des adresses IPv6 avec
l'adresse MAC dedans.
http://www.bortzmeyer.org/8064.html
----------------------------
Auteur(s) du RFC: F. Gont (SI6 Networks /
UTN-FRH), A. Cooper (Cisco), D. Thaler
(Microsoft), W. Liu (Huawei
Technologies)
Chemin des normes
----------------------------
Ce RFC parle de vie privée mais il est très court, car il se contente
de changer une règle, la nouvelle étant déjà largement acceptée.
Désormais, si une machine IPv6 configure son adresse par le système
SLAAC, et que cette adresse doit être stable dans le temps, désormais,
donc, la méthode recommandée est celle du RFC 7217 et non plus celle,
mauvaise pour la vie privée, d'utiliser l'adresse MAC. (Si l'adresse
n'a pas besoin d'être stable, aucun changement, la méthode recommandée
reste celle du RFC 4941, les adresses temporaires.)
Que veut dire SLAAC, au fait ? Ce mécanisme de configuration d'une
adresse IPv6 est normalisé dans le RFC 4862. L'idée est que la machine
écoute sur le réseau les annonces faites par les routeurs, apprenant
ainsi le·s préfixe·s IP du réseau. Elle ajoute ensuite à ce préfixe un
terme, l'identificateur d'interface (IID, cf. RFC 4291), formant ainsi
une adresse IPv6 mondiale, et unique (si l'IID est bien choisi). La
méthode originelle était de dériver l'IID de l'adresse MAC. Celle-ci
est en effet unique et, en prime, son utilisation présente certains
avantages (compression des en-têtes du RFC 6775, par exemple). Mais
s'en servir soulève plein de problèmes de sécurité et notamment de vie
privée : traçabilité des utilisateurs dans le temps, et dans l'espace
(si la machine se déplace, elle change de préfixe mais garde le même
identificateur d'interface), facilitation du balayage des adresses dans
le réseau, etc (cf. RFC 7721). D'une manière générale, réutiliser des
identificateurs d'un autre « monde » est une fausse bonne idée, souvent
dangereuse en matière de vie privée. Voilà pourquoi ce RFC dit
clairement que, désormais, il est fortement déconseillé d'utiliser les
adresses MAC. (Plusieurs mises en œuvre d'IPv6, comme celles de
Microsoft, avaient déjà cessé, avant même que ce RFC ne soit publié.)
Et ce RFC 7217 qu'il faut désormais suivre, il dit quoi ? Il propose de
fabriquer l'identificateur d'interface en condensat une concaténation
du préfixe et de diverses valeurs stables. Si on change de réseau, on a
une nouvelle adresse (on ne peut donc pas suivre à la trace une machine
mobile). Mais, si on reste sur le même réseau, l'adresse est stable.
La section 1 de notre RFC rappelle aussi la différence entre les
adresses stables et les autres. Toutes les adresses IP n'ont pas besoin
d'être stables. La solution la meilleure pour la vie privée est
certainement celle du RFC 4941, des adresses temporaires, non stables
(pour de telles adresses, on peut aussi utiliser le système des
adresses MAC si elles changent souvent par exemple avec macchanger
<https://www.it-connect.fr/changer-dadresse-mac-sous-linux-avec-macchang
er/>). Toutefois, dans certains cas, les adresses stables sont
souhaitables : l'administration réseaux est plus simple, les journaux
sont plus faciles à lire, on peut mettre des ACL, on peut avoir des
connexions TCP de longue durée, etc. Et, bien sûr, si la machine est un
serveur, ses adresses doivent être stables. Il y a donc une place pour
une solution différente de celle du RFC 4941, afin de fournir des
adresses stables. C'est seulement pour ces adresses stables que notre
RFC recommande désormais la solution du RFC 7217.
La nouvelle règle figure donc en section 3 de notre RFC : lorsqu'une
machine veut utiliser SLAAC *et* avoir des adresses stables, qui ne
changent pas dans le temps, tant que la machine reste sur le même
réseau, alors, dans ce cas et seulement dans ce cas, la méthode à
utiliser est celle du RFC 7217. L'ancienne méthode (qu'on trouve par
exemple dans le RFC 2464) d'ajouter le préfixe à l'adresse MAC ne doit
plus être utilisée.
Notez donc bien que ce RFC ne s'adresse pas à toutes les machines IPv6.
Ainsi, si vous configurez vos serveurs (qui ont clairement besoin d'une
adresse stable) à la main, avec des adresses en "leet" comme
2001:db8::bad:dcaf, ce RFC 8064 ne vous concerne *pas* (puisqu'il n'y a
pas de SLAAC).
Les RFC comme le RFC 4944, RFC 6282, RFC 6775 ou RFC 7428 devront donc
être remplacés par des documents tenant compte de la nouvelle règles.
(Cf. RFC 8065.)
Aujourd'hui, il semble que les dernières versions de Windows, iOS et
Android mettent déjà en œuvre la nouvelle règle.

[Alexandru Petrescu]

Post by Bruno STEVANT
Flute, il va falloir que l’on jette une partie des vidéos du MOOC IPv6 alors ?
En fait pas forcément, l’IID issu de l’adresse MAC va continuer à perdurer pour l’adresse lien local.
On aura donc, dans le cas général, 3 IID différents pour la même interface (1 local, 1 temporaire, 1 stable)
Du coup, est ce qu’il est toujours pertinent de désigner ces derniers 64bits comme identifiant d’*interface* ?

En plus, un seul et même IID sur deux interfaces différentes...
ne serait-ce un IAID - interface approximate identifier ?
ou un XID - id de qq chose ?

Alex

Post by Bruno STEVANT
Cordialement,

[Bruno STEVANT]

[…]
En plus, un seul et même IID sur deux interfaces différentes…

Ca c’est la question bonus pour nos étudiants quand on leur demande d'observer les interfaces virtuelles d’un routeur issue d’un trunking 1q : « Pourquoi ces interfaces ont le même IID ? Est ce que cela peut poser un problème ? » :)

[Brice ABBA]

Post by Bruno STEVANT
Ca c’est la question bonus pour nos étudiants quand on leur demande d'observer les interfaces virtuelles d’un routeur issue d’un trunking 1q : « Pourquoi ces interfaces ont le même IID ? Est ce que cela peut poser un problème ? » :)

Ceci est la force de la notion de "LIEN Local" je suis Brice ABBA quand
le parle a Bruno au telephone et je reste toujours Brice ABBA quand
parle a Stephen sur skype ;-)

[Brice ABBA]

Salut Bruno,

Flute, il va falloir que l’on jette une partie des vidéos du MOOC IPv6 alors ?En fait pas forcément, l’IID issu de l’adresse MAC va continuer à perdurer pour l’adresse lien local.
On aura donc, dans le cas général, 3 IID différents pour la même interface (1 local, 1 temporaire, 1 stable)

Pour ajouter, cela dépendra de comment l'usage de eui-64 est présenté
dans ce mooc. En effet eui-64 est l'une des méthodes utiliser pour
générer l\IID, une adresse IPv6 et cette définition tient toujours

Du coup, est ce qu’il est toujours pertinent de désigner ces derniers 64bits comme identifiant d’*interface* ?

Une adresse IP donnée, dans le monde IPv6 identifie une interface, et
une adresse IP dans IPv6 est toujours constituée des deux grandes
parties que sont la partie réseau elle même divisée en 2 parties
(préfixe de routage global et préfixe de sous réseau utilisateur) et la
partie IID (64bits). Donc cela écorche pas la définition et l'usage des
64 bits comme IID.

Une interface peut toujours avoir plusieurs adresses IPv6, du coup une
adresse ne saurait identifier un hÃŽte mais plutÃŽt une interface qui fait
parti des moyens de joindre ledit hÃŽte dans IP.

[Konstantin KABASSANOV]

Bonjour à tous,



Je me pose quand-même quelques questions existentielles sur l’exploitation des réseaux IPv6. J’avoue ne pas avoir suivi en détail toutes les discussions, mais en lisant rapidement les RFC, je ne vois pas comment projeter les rÚgles d’usage d’un réseau IPv4 en IPv6. Si j’ai bien compris, le nouvel esprit est de dire qu’une adresse IPv6 ne devrait pas pouvoir être devinée par une tierce personne.

Or à moins d’utiliser un systÚme de DNS dynamique, on n’a plus aucun moyen d’anticiper l’adresse à enregistrer. Je ne suis même pas sûr qu’on puisse enregistrer dynamiquement dans un DNS seulement les adresse IPv6 d’un hÃŽte, si ? Du coup, on fait quoi, on laisse tomber les DNS IPv6 pour les machines autre que les serveurs?

Idem pour la création d’ACLs spécifiques. Est-ce à l’utilisateur de nous fournir son adresse IPv6 générée afin de l’insérer dans les rÚgles ? Vous dites que l’adresse reste stable tant que l’interface est dans un réseau donné. Que se passe-t-il si elle bouge (et change donc d’adresse) et qu’elle revient ensuite sur son réseau d’origine ? Retrouvera-t-elle sa précédente adresse ?



Merci.



Cordialement ,

__________________________________________________________________

Konstantin KABASSANOV

LIP6/CNRS/UPMC

4, place Jussieu, BC 169, office 2600-4-10, 75252 Paris Cedex 05, France

Phone: [phone] E-mail: ***@kabassanov.com

Certificate check: http://igc.services.cnrs.fr/CNRS2-Standard/

__________________________________________________________________





De : ipv6tech-***@g6.asso.fr [mailto:ipv6tech-***@g6.asso.fr] De la part de Brice ABBA
Envoyé : lundi 27 février 2017 09:14
À : Bruno STEVANT <***@telecom-bretagne.eu>
Cc : Stephane Bortzmeyer <***@nic.fr>; ***@g6.asso.fr
Objet : Re: [IPv6-Tech] RFC 8064: Recommendation on Stable IPv6 Interface Identifiers



Salut Bruno,

Flute, il va falloir que l’on jette une partie des vidéos du MOOC IPv6 alors ?En fait pas forcément, l’IID issu de l’adresse MAC va continuer à perdurer pour l’adresse lien local.
On aura donc, dans le cas général, 3 IID différents pour la même interface (1 local, 1 temporaire, 1 stable)


Pour ajouter, cela dépendra de comment l'usage de eui-64 est présenté dans ce mooc. En effet eui-64 est l'une des méthodes utiliser pour générer l\IID, une adresse IPv6 et cette définition tient toujours




Du coup, est ce qu’il est toujours pertinent de désigner ces derniers 64bits comme identifiant d’*interface* ?

Une adresse IP donnée, dans le monde IPv6 identifie une interface, et une adresse IP dans IPv6 est toujours constituée des deux grandes parties que sont la partie réseau elle même divisée en 2 parties (préfixe de routage global et préfixe de sous réseau utilisateur) et la partie IID (64bits). Donc cela écorche pas la définition et l'usage des 64 bits comme IID.

Une interface peut toujours avoir plusieurs adresses IPv6, du coup une adresse ne saurait identifier un hÃŽte mais plutÃŽt une interface qui fait parti des moyens de joindre ledit hÃŽte dans IP.

[Bruno STEVANT]

Bonjour à tous,
Je me pose quand-même quelques questions existentielles sur l’exploitation des réseaux IPv6. J’avoue ne pas avoir suivi en détail toutes les discussions, mais en lisant rapidement les RFC, je ne vois pas comment projeter les règles d’usage d’un réseau IPv4 en IPv6. Si j’ai bien compris, le nouvel esprit est de dire qu’une adresse IPv6 ne devrait pas pouvoir être devinée par une tierce personne.

Il s’agit plus d'assurer que l’identifiant d’interface ne permette pas d’inférer plus d’informations que celles nécessaires à la fonction d’identification. De plus il y a maintenant une notion de durée de validité de cette identifiant.

Or à moins d’utiliser un système de DNS dynamique, on n’a plus aucun moyen d’anticiper l’adresse à enregistrer. Je ne suis même pas sûr qu’on puisse enregistrer dynamiquement dans un DNS seulement les adresse IPv6 d’un hôte, si ? Du coup, on fait quoi, on laisse tomber les DNS IPv6 pour les machines autre que les serveurs?

Le RFC 8064 s’applique aux adresses issues de la configuration automatique sans état (SLAAC). Cette politique s’applique majoritairement sur des postes que l’on souhaite laisser libre de se configurer, sans intervention d’un administrateur.
La nécessité d’enregistrer les adresses IP de tous les postes dans le DNS est une exigence assez forte qui à mon avis n’est pas compatible avec l’approche SLAAC. Si on souhaite imposer ce genre de règle, il me parait plus cohérent d'utiliser la configuration avec état par DHCPv6.

Idem pour la création d’ACLs spécifiques. Est-ce à l’utilisateur de nous fournir son adresse IPv6 générée afin de l’insérer dans les règles ? Vous dites que l’adresse reste stable tant que l’interface est dans un réseau donné. Que se passe-t-il si elle bouge (et change donc d’adresse) et qu’elle revient ensuite sur son réseau d’origine ? Retrouvera-t-elle sa précédente adresse ?

Les ACLs se définissent de manière générale avec la granularité du réseau, et non de la machine. Donc là pas de problème en cas de changement d’adresse, tant que celle-ci reste dans le préfixe attribué au réseau.

Cordialement,
--
Bruno STEVANT - IMT Atlantique

Merci.
Cordialement ,
__________________________________________________________________
Konstantin KABASSANOV
LIP6/CNRS/UPMC
4, place Jussieu, BC 169, office 2600-4-10, 75252 Paris Cedex 05, France
Certificate check: http://igc.services.cnrs.fr/CNRS2-Standard/
__________________________________________________________________
Envoyé : lundi 27 février 2017 09:14
Objet : Re: [IPv6-Tech] RFC 8064: Recommendation on Stable IPv6 Interface Identifiers
Salut Bruno,

Flute, il va falloir que l’on jette une partie des vidéos du MOOC IPv6 alors ?En fait pas forcément, l’IID issu de l’adresse MAC va continuer à perdurer pour l’adresse lien local.
On aura donc, dans le cas général, 3 IID différents pour la même interface (1 local, 1 temporaire, 1 stable)

Pour ajouter, cela dépendra de comment l'usage de eui-64 est présenté dans ce mooc. En effet eui-64 est l'une des méthodes utiliser pour générer l\IID, une adresse IPv6 et cette définition tient toujours

Du coup, est ce qu’il est toujours pertinent de désigner ces derniers 64bits comme identifiant d’*interface* ?

Une adresse IP donnée, dans le monde IPv6 identifie une interface, et une adresse IP dans IPv6 est toujours constituée des deux grandes parties que sont la partie réseau elle même divisée en 2 parties (préfixe de routage global et préfixe de sous réseau utilisateur) et la partie IID (64bits). Donc cela écorche pas la définition et l'usage des 64 bits comme IID.
Une interface peut toujours avoir plusieurs adresses IPv6, du coup une adresse ne saurait identifier un hôte mais plutôt une interface qui fait parti des moyens de joindre ledit hôte dans IP.
--
Mr Brice B. ABBA
facebook.com/afrinic | flickr.com/afrinic | youtube.com/afrinicmedia
----------------------------------------------------------------------------------------------------
Join us for the AFRINIC-26 meeting in Nairobi, Kenya during AIS'17, 21 May to 02 June 2017
----------------------------------------------------------------------------------------------------

['Stephane Bortzmeyer']

On Mon, Feb 27, 2017 at 10:54:00AM +0100,

je ne vois pas comment projeter les règles d’usage d’un réseau IPv4
en IPv6.

Je crois que c'est justement cela l'erreur. On ne gère pas un réseau
de capteurs dns une usine de la même façon qu'un réseau de smartphones
et tablettes dans une maison, qu'on ne gère pas comme un réseau de PC
fixes dans un bureau, qu'on ne gère pas comme des VM dans un
datacenter.

Le modèle des PC fixes, situés dans un bureau, et affectés à un
utilisateur, ne marche pas pour tous les usages.

Or à moins d’utiliser un système de DNS dynamique, on n’a plus aucun
moyen d’anticiper l’adresse à enregistrer.

Il n'y a aucune aison de mettre toutes les adresses dans le DNS, et
des tas de raisons de ne pas le faire (la vie privée, notamment).

Je ne suis même pas sûr qu’on puisse enregistrer dynamiquement dans
un DNS seulement les adresse IPv6 d’un hôte, si ? Du coup, on fait
quoi, on laisse tomber les DNS IPv6 pour les machines autre que les
serveurs?

Cela me parait logique.

Idem pour la création d’ACLs spécifiques. Est-ce à l’utilisateur de
nous fournir son adresse IPv6 générée afin de l’insérer dans les
règles ?

Étant donné que la machine peut toujours s'attribuer l'adresse qu'elle
veut, avoir des ACL par machine ne me semble pas opportun. (Sauf si on
combine avec des commutateurs fascistes qui surveillent les adresses
IP utilisées sur chaque port.)

Sinon, personnellement, je préfère me fier à ndpmon et autres systèmes
de surveillance plutôt qu'à l'email envoyé par l'utilisateur :-)

Vous dites que l’adresse reste stable tant que l’interface est dans
un réseau donné. Que se passe-t-il si elle bouge (et change donc
d’adresse) et qu’elle revient ensuite sur son réseau d’origine ?
Retrouvera-t-elle sa précédente adresse ?

Avec le RFC 7217, oui, et c'est bien son but
<http://www.bortzmeyer.org/7217.html>

[Stephane Bortzmeyer]

On Mon, Feb 27, 2017 at 12:13:53PM +0400,

la partie réseau elle même divisée en 2 parties (préfixe de routage
global et préfixe de sous réseau utilisateur)

Je ne suis pas du tout d'accord avec cette description, qui me parait
antédiluvienne (pre-VLSR).

Il n'existe pas de "préfixe de routage global", les machines dans la
DFZ peuvent avoir des politiques d'agrégation différentes.

Et il peut y avoir plus de deux longueurs de préfixe de routage (un
/32 global, un /48 dans le FAI et un /64 à la fin, par exemple).

[Au passage, grosse engueulade en ce moment à l'IETF au sujet de la
"sanctuarisation" du /64 pour les réseaux locaux.]

[Brice ABBA]

Post by Stephane Bortzmeyer
On Mon, Feb 27, 2017 at 12:13:53PM +0400,

la partie réseau elle même divisée en 2 parties (préfixe de routage
global et préfixe de sous réseau utilisateur)

Je ne suis pas du tout d'accord avec cette description, qui me parait
antédiluvienne (pre-VLSR).
Il n'existe pas de "préfixe de routage global", les machines dans la
DFZ peuvent avoir des politiques d'agrégation différentes.

Par préfixe de routage global, j'entends le préfixe de longueur "L" que
tu reçois de ton provider et que tu ne peux pas modifier. le /32 que
RIPE te donne fait parti des premier 64 bits qui constitue la partie
réseau de ton adresse IPv6.

Pour ce qui est des préférences de longueurs de préfixes a router chaque
ingénieur de trafic pourra faire ce qui convient a son réseau,

Post by Stephane Bortzmeyer
Et il peut y avoir plus de deux longueurs de préfixe de routage (un
/32 global, un /48 dans le FAI et un /64 à la fin, par exemple).

Je ne connais pas trop d'ISP qui voudrait annoncer un /64, mais dans son
propre AS, cela est tout a fait possible avec les IGP,

Post by Stephane Bortzmeyer
[Au passage, grosse engueulade en ce moment à l'IETF au sujet de la
"sanctuarisation" du /64 pour les réseaux locaux.]

en effet...

[Alexandru Petrescu]

Post by Stephane Bortzmeyer
On Mon, Feb 27, 2017 at 12:13:53PM +0400,

[...]

Post by Stephane Bortzmeyer
[Au passage, grosse engueulade en ce moment à l'IETF au sujet de la
"sanctuarisation" du /64 pour les réseaux locaux.]

AD tranche - ni sanctuarisé ni « blasphémé » (?)

[Stephane Bortzmeyer]

On Fri, Feb 24, 2017 at 03:19:07PM +0100,

Post by Bruno STEVANT
On aura donc, dans le cas général, 3 IID différents pour la même
interface (1 local, 1 temporaire, 1 stable)

Voire seulement 2 pour les machines purement clientes. Elles n'ont pas
toujours besoin d'une adresse stable.