quasIPv6-only

la chèvre et le choux… Mais la tortue qui bouge !

Le baromètre IPv6 de l'ARCEP

IPv6-only ?

Tous les sites sérieux sont aujourd'hui accessibles en IPv6.

Enfin presque tous (on a passé les 30% en 2023)

manquent github.com, www.univ-amu.fr et caf.fr …

D'après google, en france 75% des accès sont en IPv6 (janvier 2024)

Au moins un tiers des sites "les plus consultés"© sont accessibles en IPv6… pas le tien ? 😱

Question SSI toute bête: ok, tu ne gères pas IPv6… si j'annonce un routeur IPv6 sur un LAN il se passe quoi ?

Encore plus rigolo: un routeur IPv6-only avec un DNS "DNS64" dans l'annonce et l'option "prefer64" ?

(Oui, il existe du ra-guard, dhcpv6-snooping, nd-snooping… mais pas activé ça ne sert à rien)

Une étude des mécanismes de sécurité LAN pour comware5/7

Bref, il faut au moins commencer…

Sauf que ça ajoute un niveau 3 à gérer

  • Distribution/allocation des adresses (facile)
  • Filtrage (double travail)
  • Monitoring (double travail)

Et si on enlève IPv4 ?

Pas (encore) partout… mais c'est assez simple

  • Pour les serveurs «backend»
  • Pour les services internes à une structure dont les réseaux sont compatibles IPv6

TIPS serveur IPv6-only

A connaître:

  • Linux: 
    sysctl net/ipv6/bindv6only #=0?
  • FreeBSD: 
    sysctl net.inet6.ip6.v6only #=1

Java: 

-Djava.net.preferIPv4Stack=false -Djava.net.preferIPv6addresses=true

Ok. mais j'ai besoin de faire un git clone depuis github sur mon «backend»

En fait un serveur c'est un peu aussi un client parfois …

utilise framagit ! 😈

Les «clients»

  1. Utilisateurs (tip: ils s'en foutent s'ils ne connaissent pas la tortue)
  2. Machines: Deux types de problèmes
    • Système récent (< 15 ans) et code "agnostique"
    • Système ancien
    • code qui manipule des IPv4 (p2p, visio, tout système qui ne passe pas par le DNS)

Client «récent»

On utilise deux techniques

  • DNS64 (rfc6147) 
    module-config: "dns64 validator iterator"
	dns64-prefix: 64:ff9b::/96     # well-known prefix (default)
  • NAT64 (rfc6146) 
    pass in quick inet6 from $myv6net to 64:ff9b::/96 af-to inet from (ext_if)

Comme dans 128 bits on peut en mettre 32

github.com (140.82.121.3) devient PREFIXE::8c52:7903

le DNS ajoute donc un enregistrement AAAA s'il n'existe pas, qui embarque l'IP contenue dans le A

Le routeur va «reconnaitre» le préfix dédié et extraire l'IPv4 des 32 derniers bits

Les autres clients

Le très vieux: Ben on va lui laisser de l'IPv4 !

Comme il ne va pas demander l'option DHCP 108 "IPv6-only prefered", il va prendre une IPv4.

… on y revient dans 2 slides ;)

Les autres clients

pour le cas de l'appli qui ouvre un socket IPv4 explicitement… (elle sont plusieurs)

  • On peut utiliser le CLAT (Customer-side address translator) défini dans 464XLAT (rfc8677) comme font les opérateurs mobiles tiens… Si et seulement si on a un système compatible CLAT: Android©, IOS©, MacOSX©, et même M$ Windows© 🤩 …mais seulement avec un modem GSM 🤯

CLAT c'est quoi ?

C'est une autre façon d'utiliser notre «préfixe 64» (ou un autre d'ailleurs)

  • le client «découvre» le préfixe (on y revient)
  • Il crée une interface locale avec une IPv4 (192.0.0.0/29 - rfc7335)
  • Les paquets sortent "traduits" en IPv6 (le routeur qui reconnaitra le préfixe fera suivre à l'IPv4 embarquée)
  • -> on peut ping 8.8.8.8

Test: ton mobile a-t-il de l'IPv4 ou juste 192.0.0.X ❓

Bon_ et comment on donne des IPv4 à certains clients et pas à d'autres ?

C'est le kit «IPv6-Mostly»:

  • rfc8925 - dhcp option "IPv6-only prefered"
  • rfc8781 - router-advertisement pref64
  • rfc7050 - detection/validation du préfixe par le DNS

rfc7050

Détection et validation du préfixe IPv6 utilisé pour le CLAT

La seule vraie réponse pour ipv4only.arpa. est 192.0.0.170 (c000:00aa) et 192.0.0.171 (c000:00ab)


	(drill -t AAAA ipv4only.arpa.)> 2001:db8:64::c000:aa
	(-t PTR 2001:db8:64::c000:aa)> dns64.example.com
	(-t AAAA dns64.example.com.)> 2001:db8:64::c000:aa # préfixe validé
	(-t A dns64.example.com)> 192.0.2.80 # IPv4 pour test connectivité

rfc7050 2/2

unbound.conf

module-config: "dns64 validator iterator"
	#dns64-prefix: 64:ff9b::/96     # well-known prefix (default)
	#local-zone: "ipv4only.arpa." static
	#local-data: "ipv4only.arpa. IN AAAA 2a01:e0a:c21:64::c000:ab"
	#local-data: "ipv4only.arpa. IN AAAA 2a01:e0a:c21:64::c000:aa"

Ok. c'est compliqué, c'est poilu… je le veux à la maison ! Je fais comment ?

Ça tombe bien, avec ton routeur OpenBSD c'est assez simple:

  • /etc/dhcpd.conf: 
    option option-108 00:00:0e:10; # rfc8925 - 3600s en hex
  • /etc/pf.conf: 
    pass in quick inet6 from $myv6net to 64:ff9b::/96 af-to inet from ($ext_if)# rfc6146
  • /etc/rad.conf: 
    nat64 prefix 64:ff9b::/96 # rfc8781
  • /var/unbound/etc/unbound.conf: comme au dessus

Support inégal chez les "gros" constructeurs

  • rfc6146 (NAT64) chez cisco, juniper, F5…
  • rfc8781 (pref64 RA) chez cisco
  • Les autres sont en général implémentées en soft (bind/unbound/knot, isc-dhcp/kea/…)

HOWTO CLAT

Linux (debian)

  • On peut installer clatd qui utilise la rfc7050 pour déterminer le préfixe à utiliser
  • dhclient (isc) connait l'option v6-only-preferred, mais il faut l'ajouter explicitement dans /etc/dhcp/dhclient.conf
  • Si NetworkManager, il faut lui spécifier d'utiliser dhclient: 
    [main]
dhcp=dhclient

OpenBSD

pkg_add gelatod
	man gelatod

OpenWRT

https://ripe87.ripe.net/presentations/8-IPv6-mostly_on_OpenWRT.pdf