Hello IPv6 fellows 

Je commence avec un peu de contexte:

• Je suis chez Orange en FTTH avec un ERL à la place de la box, et j’annonce donc des /64 sur mes VLANs à partir du /56 distribué par Orange, préfixe globalement fixe mais... qui peut changer
• J’ai un serveur DNS (sur 2 NAS Synology pour avoir un maître et un esclave) qui expose mes services locaux en IPv6. Problème: Quand le préfixe change (ça m’est déjà arrivé une fois), je dois renuméroter tous mes enregistrements AAAA, et également modifier la configuration de certains services (comme le mynetworks de postfix...)

Donc ce matin je me suis dis « Et si j’annonçais en plus du préfix global routable un préfix non routable tiré du bloc ULA ? ». Ca me permettrait de mettre dans mon serveur DNS des enregistrements AAAA qui ne changeraient pas tout en conservant une connectivité globale en IPv6 pour sortir de mon LAN.

Du coup je mets tout ça en place, et à ma grande surprise, je me rend compte que mes Macs et appareils iOS se mettent à préférer IPv4 au lieu de IPv6 ULA (Alors qu’ils préféraient IPv6 Global à IPv4). D’un autre coté, mes Debian/Ubuntu préfèrent bien toujours IPv6 à IPv4.

Après un peu de recherches, je me rend compte que MacOS/iOS implèmentent le tableau de précédence de la RFC 6724, et qu’il est donc normal qu’IPv4 soit préféré à IPv6 ULA... De son coté, sur mes Debian/Ubuntu, la table de précédence (dans /etc/gai.conf) est légèrement différente...

Du coup je me pose 2 questions:

• Y-a-t’il un moyen de changer la table de macOS (pour iOS j’ai peu d’espoir) ?
• Les adresses ULA c’est de la merde dans un environnement dual stack et je n’aurais jamais du l’utiliser ?

Oui, j’ai évidemment des enregistrements A & AAAA...

Pour résumer:

• A + AAAA ULA => MacOS choisi le A
• A + AAAA UGA => MacOS choisi le AAAA

Je tenterais bien de virer mes enregistrements A, ce qui résoudrait de fait le problème, mais pour l’instant j’ai du mal à évaluer l’impact sur l’ensemble des clients de ces services...

La vue DNS est une possibilité à étudier...

Sinon j’avais effectivement envisagé de faire des updates dynamiques de mes enregistrements depuis l’ERL quand le préfixe change, et du coup de ne pas avoir d’ULA du tout, mais d’une part j’avais la flemme de scripter  et d’autre part je ne suis pas certain de pouvoir faire ça sur l’ERL sans devoir installer des paquets supplèmentaires, ce que je voudrais éviter.

Ils ont les 2.

D’aillleurs si je force une connexion IPv6 (genre ssh -6) vers un hôte qui a un enregistrement A + AAAA ULA alors la connexion fonctionne, et c’est bien l’IP ULA qui est utilisée (vérifié avec la commande w).

Mon /etc/gai.conf (Ubuntu 17.10) est vide (entièrement commenté), ce n'est pas le cas sur MacOS X ?

$ cat /etc/gai.conf
# Configuration for getaddrinfo(3).
#
# So far only configuration for the destination address sorting is needed.
# RFC 3484 governs the sorting.  But the RFC also says that system
# administrators should be able to overwrite the defaults.  This can be
# achieved here.
#
# All lines have an initial identifier specifying the option followed by
# up to two values.  Information specified in this file replaces the
# default information.  Complete absence of data of one kind causes the
# appropriate default information to be used.  The supported commands include:
#
# reload  <yes|no>
#    If set to yes, each getaddrinfo(3) call will check whether this file
#    changed and if necessary reload.  This option should not really be
#    used.  There are possible runtime problems.  The default is no.
#
# label   <mask>   <value>
#    Add another rule to the RFC 3484 label table.  See section 2.1 in
#    RFC 3484.  The default is:
#
#label ::1/128       0
#label ::/0          1
#label 2002::/16     2
#label ::/96         3
#label ::ffff:0:0/96 4
#label fec0::/10     5
#label fc00::/7      6
#label 2001:0::/32   7
#
#    This default differs from the tables given in RFC 3484 by handling
#    (now obsolete) site-local IPv6 addresses and Unique Local Addresses.
#    The reason for this difference is that these addresses are never
#    NATed while IPv4 site-local addresses most probably are.  Given
#    the precedence of IPv6 over IPv4 (see below) on machines having only
#    site-local IPv4 and IPv6 addresses a lookup for a global address would
#    see the IPv6 be preferred.  The result is a long delay because the
#    site-local IPv6 addresses cannot be used while the IPv4 address is
#    (at least for the foreseeable future) NATed.  We also treat Teredo
#    tunnels special.
#
# precedence  <mask>   <value>
#    Add another rule to the RFC 3484 precedence table.  See section 2.1
#    and 10.3 in RFC 3484.  The default is:
#
#precedence  ::1/128       50
#precedence  ::/0          40
#precedence  2002::/16     30
#precedence ::/96          20
#precedence ::ffff:0:0/96  10
#
#    For sites which prefer IPv4 connections change the last line to
#
#precedence ::ffff:0:0/96  100

#
# scopev4  <mask>  <value>
#    Add another rule to the RFC 6724 scope table for IPv4 addresses.
#    By default the scope IDs described in section 3.2 in RFC 6724 are
#    used.  Changing these defaults should hardly ever be necessary.
#    The defaults are equivalent to:
#
#scopev4 ::ffff:169.254.0.0/112  2
#scopev4 ::ffff:127.0.0.0/104    2
#scopev4 ::ffff:0.0.0.0/96       14

il y a une rfc récente ( https://tools.ietf.org/html/rfc7078 ) pour eventuellement changer la policy par DHCPv6.

c'est l'option dhcpv6 "OPTION_ADDRSEL 84" (et 85).

reste a voir si osx & ios la supporte .