La Fibre
Télécom => Réseau => 
IPv6 => Discussion démarrée par: zoc le 10 février 2018 à 12:01:45
-
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 ?
-
Hello,
Oh, un sujet technique sur v6 <3
J'ai pas bien compris ton histoire de préférence...
Tu veux utiliser de l'ULA pour accéder à tes services locaux en v6, c'est ça ?
Du coup, si tu mets un record AAAA avec une ULA, je ne vois pas comment il pourrait passer en v4 ?
À moins que tu n'ai un record A avec ton IPv4 et un AAAA avec une ULA ?
;D
-
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...
-
Avec une vue DNS, ça ne résoudrait pas ton souci ?
Une vue locale avec juste du v6
Une vue globale avec juste du v4 ou du dual stack avec ton préfixe Orange (tu peux même scripter pour le changer dynamiquement amha)
:)
-
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 ;D 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.
-
tes mac ont bien aussi une IPv6 ULA ou juste la globale (GUA)?
-
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).
-
mouais donc t'as pas trop le choix :o virer l'entrée A dans le DNS.
-
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 n’existe pas sur OSX.
Et effectivement par défaut le contenu de gai.conf est entièrement commenté. Maintenant le problème c’est qu’il y a 2 RFC différentes qui traitent du sujet de la sélection d’adresse: La RFC 3484, implèmentée par Linux, et la RFC 6724 implèmentée par MacOS et les 2 n’ont pas la même table de précédence...
Manifestement la 3487 est rendue obsolète par 6724, donc sur ce point Linux est à la traîne (mais à un comportement qui me paraît plus logique )
-
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 .
-
Je ne fais pas de DHCPv6 pour le moment sur mon LAN (juste du SLAAC), et d'après ce que j'ai compris sur les forum d'ubnt, il est assez difficile de faire du DHCP6 stateless sur EdgeOS si tu n'utilises pas en même temps leur implèmentation de DHCP6-PD client (qui génère le radvd.conf et la conf du serveur DHCP6 automatiquement). Sachant qu'elle n'est pas utilisable chez Orange... (et que j'ai du coup un script qui génère radvd.conf).
-
t'avais essayé avec le 'trick' d'utiliser les adresses link-local/128 pour l'activer sur les interfaces sans activer le statefull:
service {
dhcpv6-server {
name-server <IPv6 address of DNS server 1>
name-server <IPv6 address of DNS server 2>
shared-network-name STATELESS {
subnet <IPv6 link-local address of eth0>/128 {
...
}
subnet <IPv6 link-local address of eth1>/128 {
...
}
...
}
}
}
pas oublier d'ajouter l'option qui va bien au RA pour que les postes facent une requete DHCPv6.
-
Oui, j'ai vu ça dans un post sur le forum d'ubnt, mais du coup c'est ça qui ne me plait pas, car j'ai 2 ERL (Je les intervertis à chaque mise à jour du firmware, ce qui me permet de faire la mise à jour et les modifications manuelles offline, et donc limiter le downtime et rester dans le WAF ;D): Du coup évidemment ils n'ont pas la même adresse Link-local...
Sinon j'ai la possibilité de générer le fichier de config dhcp6s avec un script comme je le fais pour radvd et lancer le serveur dhcp6. Je testerai à l'occasion, bien que je doute que macOS/iOS supporte la rfc7078 (trop récent).
-
Oui, j'ai vu ça dans un post sur le forum d'ubnt, mais du coup c'est ça qui ne me plait pas, car j'ai 2 ERL (Je les intervertis à chaque mise à jour du firmware, ce qui me permet de faire la mise à jour et les modifications manuelles offline, et donc limiter le downtime et rester dans le WAF ;D): Du coup évidemment ils n'ont pas la même adresse Link-local...
y'a un autre trick que j'avais posté sur leur forum: https://community.ubnt.com/t5/EdgeMAX/Stateless-DHCPv6/m-p/1744684/highlight/true#M137831
en gros tu ajoute une autre link-local aux interfaces comme cela le fichier de conf est indépendant du matériel.
-
J’avais même pas fait attention que tu avais participé au fil :)
Oui, je peux éventuellement rajouter une adresse link-local...
-
Des news sur ce sujet: J'ai mis en place DHCP6 Stateless sur mon VLAN principal (mes autres VLAN ne contiennent que des Linux avec adressage statique) en utilisant les recommendations de @kgersen sur le forum d'ubnt.
Ce qui m'a ensuite permis d'analyser les requêtes DHCP6 de mes machines/smartphones/tablettes macOS/iOS. Et là clairement, aucune plateforme ne fait une demande d'option qui pourrait ressembler de près ou de loin à la RFC7078. Du coup je n'ai pas cherché plus loin (genre forcer l'option 84/85 en retour), j'ai gardé DHCP6 Stateless (même si les plateformes Apple se contentent du SLAAC + RDNSS dans les faits).
Ce WE j'ai viré (commenté ;) ) tous les enregistrements A de mes zones internes, et à part quelques petits problèmes ponctuels (le SNMP/SSH/WEB de mon ERL qui n'écoutait que sur une IPv4), tout semble fonctionner comment avant. Du coup tous mes services internes sont maintenant attaqués exclusivement en IPv6.