IPv6 » Historique » Version 94
Version 93 (Bernard Urban, 03/02/2013 00:02) → Version 94/318 (Bernard Urban, 03/02/2013 00:03)
{{>toc}}
h1. IPv6
Déploiement a tetaneutral.net : #35
h2. Liens
[[WorldIPv6Launch20120606]]
General
* http://en.wikipedia.org/wiki/ICMPv6
* http://en.wikipedia.org/wiki/Neighbor_Discovery_Protocol
* http://en.wikipedia.org/wiki/Radvd
* http://en.wikipedia.org/wiki/DHCPv6
** https://wikispaces.psu.edu/display/ipv6/DHCPv6
* http://www.iana.org/assignments/icmpv6-parameters
Statistics
* http://bgp.he.net/ipv6-progress-report.cgi
* https://labs.ripe.net/Members/mirjam/content-ipv6-measurement-compilation
* http://www.ripe.net/internet-coordination/ipv4-exhaustion/ipv4-available-pool-graph
* http://www.google.com/ipv6/statistics.html
* http://julien.vaubourg.com/files/lothaire-yarding_ipv6.pdf
* https://www.ams-ix.net/technical/statistics/sflow-stats/ipv6-traffic
Linux
* http://madduck.net/docs/ipv6/
* http://tldp.org/HOWTO/Linux+IPv6-HOWTO/
* http://linux.die.net/man/8/rdisc6
* bind IPv4+IPv6 /proc/sys/net/ipv6/bindv6only http://www.kernel.org/doc/man-pages/online/pages/man7/ipv6.7.html
* sileht : comme arpwatch mais en ipv6 http://ndpmon.sourceforge.net/
* sileht : proxy NDP auto http://www.priv.nu/projects/ndppd/ et https://github.com/Tuhox/ndppd
* dachary : hairpin_mode issue nova https://bugs.launchpad.net/nova/+bug/1011134
* https://wiki.archlinux.org/index.php/IPv6
Tunnels
* http://en.wikipedia.org/wiki/List_of_IPv6_tunnel_brokers
* http://tunnelbroker.net
* http://sonic.net/features/ipv6/
Misc
* Cool IPv6 stuff http://www.sixxs.net/misc/coolstuff/
* http://interviews.slashdot.org/story/11/10/25/1532213/vint-cerf-answers-your-questions-about-ipv6-and-more
* http://infosecblog.antonaylward.com/2010/08/05/re-opensuse-ipv6-nat-was-113-and-ssh-x-forwarding-not-working/
* conférence JRES 2011 http://stream.ut-capitole.fr/jres2011/57.html
* http://vincent.riquer.fr/blog/archives/2010/04/11/openvpn__ipv6__bind__happiness/index.html
* http://blog.si6networks.com/2012/02/ipv6-nids-evasion-and-improvements-in.html
* https://vador.fdn.fr/wiki/support:faq:ipv6
* http://blog.si6networks.com/2012/02/ipv6-nids-evasion-and-improvements-in.html
* http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-first_hop_security.html#wp1054246
* http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard-implementation-01
* http://www.ripe.net/lir-services/training/material/IPv6-for-LIRs-Training-Course/IPv6_addr_plan4.pdf
Opérateurs
* DS-Lite chez FT http://www.ietf.org/mail-archive/web/v6ops/current/msg10652.html
* IPv6 chez comcast http://tech.slashdot.org/story/11/11/09/174217/comcast-begins-native-ipv6-deployment-to-end-users
* DHCP-PD http://ipv6.internode.on.net/
* Ninux [[AirOS]] vs [[OpenWRT]] retour d'experience http://blog.ninux.org/2012/06/06/the-ipv6-deployment-in-the-ninux-community-network/
Tests
* http://ip6.nl/
h2. RIPE
* IPv6 Address Allocation and Assignment Policy
** http://www.ripe.net/ripe/docs/ripe-552
* RIPE Routing Working Group Recommendations on IPv6 Route Aggregation
** http://www.ripe.net/ripe/docs/ripe-532
h2. Configuration d'un LAN « IPv6 only » sous debian
* [[NAT64DNS64]]
* [[THSF 2012]]
h2. Debian
* http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=643594
** ebtables: v2.0.10-1 wish for ipv6-icmp and security
** fixé le 5 juin 2012
** voir aussi [[Spoofing]]
h2. Discovery
RFC4291 https://tools.ietf.org/html/rfc4291
Pinging the multicast address ff02::1 results in all hosts in link-local scope responding. An interface has to be specified. With a ping to the multicast address ff02::2 only routers will respond.
If you add an option -I <your-global-ipv6>, link-local hosts will respond with their link-global scope addresses.
h2. Désactiver la configuration automatique
http://lists.tetaneutral.net/pipermail/technique/2011-November/000086.html
Un serveur aura typiquement une configuration entièrement statique assignée par l'hébergeur, laisser la configuration dynamique activée est un risque de voir un tiers prendre le controle du routage serveur ou l'empécher de fonctionner via l'envoi d'une configuration dynamique erronée. Il est donc préférable de désactiver la configuration dynamique IPv6 sur une VM ou serveur physique hébergé chez tetaneutral.net. Si votre VM est en mode routeur (c'est à dire la commande "more /proc/sys/net/ipv6/conf/all/forwarding" renvoit 1), cette désactivation est implicite, voir dans le source du noyau Linux le fichier "Documentation/networking/ip-sysctl.txt")
En version rapide executer sur sa VM ou machine en root la ligne suivante :
<pre>
wget -qO - http://tetaneutral.net/ipv6/ipv6noauto.sh | bash
</pre>
Le détail de ce que fait ce script ci-après.
h3. Désactiver autoconf et accept_ra pour la session en cours
Executer en root la ligne suivante :
<pre>
for i in /proc/sys/net/ipv6/conf/*; do for j in autoconf accept_ra; do echo 0 > $i/$j; done;done
</pre>
h3. Le rendre permanent en cas de reboot
Editer la section inte6 de /etc/network/interfaces pour ajouter deux "pre-up" entre la ligne "iface" et la ligne "address" :
<pre>
iface eth0 inet6 static
pre-up echo 0 > /proc/sys/net/ipv6/conf/$IFACE/accept_ra
pre-up echo 0 > /proc/sys/net/ipv6/conf/$IFACE/autoconf
address ...
</pre>
Créer un fichier pour sysctl :
<pre>
cat > /etc/sysctl.d/local-ipv6.conf <<EOF
# No IPV6 RA or autoconf
net.ipv6.conf.all.autoconf = 0
net.ipv6.conf.all.accept_ra = 0
net.ipv6.conf.default.autoconf = 0
net.ipv6.conf.default.accept_ra = 0
EOF
</pre>
h3. Référence : source du script ipv6noauto.sh
<pre>
echo deactivating autoconf and accept_ra
for i in /proc/sys/net/ipv6/conf/*; do
for j in autoconf accept_ra; do
echo $i/$j
echo 0 > $i/$j
done
done
F=/etc/network/interfaces
if ! grep accept_ra $F >& /dev/null; then
echo fixing /etc/network/interfaces
cp -f $F $F.save
sed -e 's,iface eth0 inet6 static,iface eth0 inet6 static\n pre-up echo 0 > /proc/sys/net/ipv6/conf/$IFACE/accept_ra\n pre-up echo 0 > /proc/sys/net/ipv6/conf/$IFACE/autoconf,g' < $F.save > $F
fi
if [ ! -f /etc/sysctl.d/local-ipv6.conf ]; then
echo creating /etc/sysctl.d/local-ipv6.conf
cat > /etc/sysctl.d/local-ipv6.conf <<EOF
# No IPV6 RA or autoconf
net.ipv6.conf.all.autoconf = 0
net.ipv6.conf.all.accept_ra = 0
net.ipv6.conf.default.autoconf = 0
net.ipv6.conf.default.accept_ra = 0
EOF
fi
echo done
</pre>
h2. ARP cache limits
TODO via Cyril B.
<pre>
net.ipv6.neigh.default.gc_thresh1 = 1024
net.ipv6.neigh.default.gc_thresh2 = 2048
net.ipv6.neigh.default.gc_thresh3 = 4096
</pre>
h2. Pièges
Attention a bien mettre les zéros en fin de mot :
Ne pas mettre 2a01:6600:8081:XX:: car c'est 2a01:6600:8081: *00* XX::
Utiliser 2a01:6600:8081: *XX00* ::
h2. Comment activer le routage sur son /56 IPv6 ?
Chaque IPv4 livrée par tetaneutral.net est associé à un /56 IPv6, avec une équivalence /24 = 256 IPv4 <=> /48 = 256 /56 IPv6
h2. Discussions
> J'ai fait quelques essais: VM configuré en routeur, openvpn entre la VM
> et ma machine, histoire de simuler des interfaces. J'ai essayé radvd
> comme des définitions manuelles des adresses IPv6.
>
> Bon, ça marche depuis la VM mais pas depuis chez moi (wget
> http://ipv6.google.com), même si les paquets IPv6 (vu avec tcpdump)
> partent bien de la VM vers l'internet. Mais il n'y a pas de retour.
>
> Après quelques cogitations et la lecture de ceci:
> http://www.fdn.fr/IPv6-a-la-maison.html j'en arrive à ces
> réflexions:
>
> 1) Dans le blog FDN ci-dessus l'adresse IPv6 affectée au ppp0 n'est pas
> dans son /48; ce qui voudrait dire qu'il n'y a pas de raison d'affecter
> une IPv6 du /56 au eth0 des VM tetaneutral.
>
> 2) Pour faire marcher une telle config à FDN, le routeur FDN en amont du
> modem/routeur de l'abonné devrait avoir une route du type:
> ip -6 route add range/48 dev ppp-abonné via link-local-ppp-abonné
> soit chez nous:
> ip -6 route add range/56 dev eth0-vm via link-local-eth0-vm
>
> > du /56 via une interconnection explicite entre le routeur de
> > tetaneutral.net et un routeur chez le membre ?
>
> Un lien openvpn?
Bonsoir,
On peut rajouter une regle de routage comme tu le suggere,
reste a choisir les details pratiques.
Pour la link-local coté routeur on a choisi fe80::31 en statique il
reste a choisir une regle pour attribuer le link local coté client.
Une regle automatique basée sur l'IPv4 est en place pour
l'attribution du subnet IPv6 :
http://wiki.tetaneutral.net/index.php/Architecture
Une regle similaire pour le routage donnerait par exemple fe80::81:XY
ou XY est le dernier octet de l'IPv4 ecrit en hexadecimal
pour la link local coté client.
L'avantage d'une regle statique vs le SLAAC c'est que c'est un peu plus
flexible coté client sur le choix de l'equipement routeur.
L'avantage du routé est bien sur la flexibilité et la sécurisation
potentielle, l'inconvenient est qu'avec nos equipements actuels peu
puissant on perdra un peu en debit mais ça se corrigera avec
de nouveaux equipements.
Je suis vraiment curieux de savoir comment font les autres hebergeurs
dans le monde IPv6, ceux auxquels j'ai acces ne proposent pas de
routage, simplement ce que propose tetaneutral.net actuellement.
Suggestions ?
h2. Connectivité IPv6 complète depuis chez vous en quelques étapes simples
Connectivité complète signifie que toutes vos machines pouvant fonctionner en IPv6 peuvent accéder des sites IPv6 externes mais surtout être joignables de l'extérieur sur une adresse IPv6 propre. Pas de NAT ou autre bidouille de ce genre. Implications en terme d'autohébergement et sécurité laissées en exercice.
Pour bien comprendre ce qui suit, il est recommandé d'avoir un peu potassé les hyperliens plus haut et mieux encore d'avoir joué avec l'IPv6 sur votre réseau local maison en utilisant par exemple des adresses ULA.
h3. Etape 1: obtenir une machine virtuelle Tetaneutral.
Celle-ci (on l'appellera VM dans la suite) sera configurée par défaut comme suit dans /etc/network/interfaces du point de vue IPv6:
<pre>
iface eth0 inet6 static
# les 2 lignes qui suivent ne seront pas nécessaires lorsque
# plus loin nous passerons en mode routeur
pre-up echo 0 > /proc/sys/net/ipv6/conf/$IFACE/accept_ra
pre-up echo 0 > /proc/sys/net/ipv6/conf/$IFACE/autoconf
address 2a01:6600:80XX:YY00::1
netmask 56
gateway fe80::31
</pre>
où XX et YY sont les versions hexadécimales des xx et yy décimaux de votre (unique!) adresse IPv4 de la forme 91.224.xx.yy.
Voyons ce qu'implique la prise en compte par le système de ce fragment de /etc/network/interfaces. Il dit que:
# l'adresse 2a01:6600:80XX:YY00::1 est affectée à eth0, ce qui signifie que votre VM est accessible à cette adresse depuis l'intérieur de la VM comme depuis l'extérieur par toutes les machines du même segment réseau que eth0
# les paquets passant par votre VM peuvent atteindre les adresses de la plage 2a01:6600:80XX:YY00::/56 en étant envoyés en sortie de l'interface eth0
La plage 2a01:6600:80XX:YY00::/56 a été allouée par tetaneutral à votre VM. Notre problème est d'allouer une partie de ces adresses à des machines de notre domicile en utilisant l'accès que nous avons (en IPv4!) à la VM.
Avec cette configuration, vous pouvez héberger sur la VM des milliards de serveurs avec des adresses IPv6 différentes, il suffit de les ajouter à eth0 par une commande du type:
<pre>
ip -6 address add une-adresse-ipv6-de-votre-plage/56 dev eth0
</pre>
Le /56 n'est pas absolument nécessaire, il évite juste de rajouter une route plus spécifique pour atteindre votre nouvelle adresse IPv6 depuis votre VM, route qui s'avère redondante.
Le lecteur attentif aura noté que cette configuration déclare que toutes les adresses de votre plage sont situées derrière eth0, en dehors de la partie contrôlée par votre VM, et il semble impossible alors d'en distraire une partie. Il y a au moins deux solutions à ce problème:
# S'arranger pour que les segments réseau de votre domicile fassent partie de celui partant de eth0 sur la VM. Celà revient techniquement à bridger ces segments réseaux. Cette solution a cependant des inconvénients en terme de configurabilité et de sécurité.
# Réduire la plage IPv6 allouée derrière l'eth0 de la VM et réallouer le solde à votre réseau local maison, par des techniques de routage. C'est ce qu'on va décrire dans la suite. Mais d'abord, on a besoin d'un peu de collaboration de Tetaneutral.
h3. Etape 2: faire router votre plage /56 par Tetaneutral.
Dans la configuration par défaut des VM Tetaneutral, l'hôte des VM crée la route vers l'adresse 2a01:6600:80XX:YY00::1 (et des autres que vous rajoutez éventuellement à la main sur eth0) par l'utilisation de l'équivalent IPv6 d'ARP. Il est donc impossible de router vers une adresse qui n'existe pas sur cet eth0.
Tetaneutral doit donc rajouter une route explicite:
<pre>
ip -6 route add 2a01:6600:80XX:YY00::/56 via fe80::XX:YY dev votre-eth0-côté-hôte
</pre>
Celà n'a de sens que si fe80::XX:YY une des adresses de l'eth0 côté VM. Il faut donc l'ajouter et le mieux est de le faire via une directive 'up' dans /etc/network/interfaces:
<pre>
iface eth0 inet6 static
# les 2 lignes qui suivent ne seront pas nécessaires lorsque
# plus loin nous passerons en mode routeur
pre-up echo 0 > /proc/sys/net/ipv6/conf/$IFACE/accept_ra
pre-up echo 0 > /proc/sys/net/ipv6/conf/$IFACE/autoconf
address 2a01:6600:80XX:YY00::1
netmask 64
gateway fe80::31
up ip -6 add add fe80::XX:YY dev eth0
</pre>
Mon lecteur toujours très attentif n'aura pas manqué de noter que netmask ci-dessus est passé de 56 à 64. Nous n'allouons donc maintenant plus toutes nos adresses IPv6 sur le segment réseau partant d'eth0. En particulier, nous allons voir maintenant comment récupérer la sous-plage 2a01:6600:80XX:YY01::/64 pour notre réseau à domicile.
+Remarque:+ la sous-plage doit être /64, sinon l'adressage automatique des interfaces réseau qu'on verra plus loin ne marchera pas.
h3. Etape 3: simuler un lien ethernet entre une machine à domicile et cette VM.
Les technologies VPN/tunnel sont le pendant réseau des machines virtuelles: elles permettent de créer des interfaces réseaux virtuelles (du point de vue hardware, mais bien réelles d'un point de vue logiciel) et de les connecter entre elles.
Tout comme les machines virtuelles nécessitent quand même un minimum de support silicium, un VPN/tunnel va nécessiter de s'appuyer sur une vraie liaison entre deux vraies interfaces réseau, en l'occurence pour nous la liaison internet IPv4 entre autre utilisée pour l'administration de la VM depuis votre domicile. Plus précisément, nous allons utiliser l'outil openvpn.
La première étape va consister à installer openvpn en mode serveur sur la VM. Le fichier suivant est à créer dans /etc/openvpn/myris.conf:
<pre>
dev tap
proto udp
local 91.224.xx.yy
float
ca myris/ca.crt
cert myris/myris.crt
key myris/myris.key
dh myris/dh1024.pem
tls-server
port 1194
ping 15
ping-restart 45
# car serveur
ping-timer-rem
persist-tun
persist-key
ifconfig 10.0.0.2 255.255.255.252
route ipv4-adresse-client-openvpn-domicile 255.255.255.255 10.0.0.1
script-security 3 system
route-up "/sbin/ip -6 addr add 2a01:6600:80XX:YY01::1/64 dev tap0"
</pre>
+Remarque:+ le paramètre route-up contient le nom 'tap0' codé en dur, ce qui n'est pas portable. Cette commande est nécessaire pour créer sur la VM une route vers la bonne interface pour la plage 2a01:6600:80XX:YY01::/64. Pour que le serveur openvpn soit toujours présent, il faut ajouter
<pre>
AUTOSTART="myris"
</pre>
à /etc/default/openvpn.
Sur la machine à domicile, il faut une installation en mode client, pourquoi pas le même nom de fichier que le serveur, mais pas le même contenu:
<pre>
dev tap
proto udp
local ipv4-adresse-client-openvpn-domicile
remote 91.224.xx.yy
ca myris/ca.crt
cert myris/client.crt
key myris/client.key
tls-client
port 1194
ping 15
ping-restart 45
persist-tun
persist-key
ifconfig 10.0.0.1 255.255.255.252
route 0.0.0.0 0.0.0.0 10.0.0.2
</pre>
L'adresse ipv4-adresse-client-openvpn-domicile est toute adresse qui permet d'accéder Internet depuis la machine accueillant l'openvpn client; en général, ce ne sera donc pas votre adresse IP externe allouée par votre FAI, elle sera plutôt du genre 192.168.*.*. ou 10.*.*.*. Il est supposé bien sûr dans l'exemple ci-dessus que vous n'utilisez pas 10.0.0.0/30 chez vous, elle a été réservée au lien openvpn.
Les répertoires /etc/openvpn/myris sur VM et machine cliente contiendront les divers certificats et clés, qu'il faut générer. Voici comment faire:
<pre>
cd un-répertoire de travail
cp -R /usr/share/doc/openvpn/examples/easy-rsa/2.0/ .
cd 2.0
# Editez à votre convenance les 5 dernières variables d'environnement de type KEY_* du fichier vars
source ./vars
./clean-all
./build-dh
./pkitool --initca
./pkitool --server myris
./pkitool client
</pre>
et les fichiers recherchés se trouvent dans le sous-répertoire keys. Le seul fichier commun aux 2 extrémités du lien openvpn est ca.crt.
h3. Etape 4: passer la VM en mode routeur et annoncer des routes pour votre réseau à domicile avec radvd.
Pour autoriser les paquets à être routés sur la VM entre eth0 et tap0, il faut passer en mode routeur:
<pre>
echo 1 >/proc/sys/net/ipv6/conf/all/forwarding
</pre>
Il est encore mieux de conserver ce mode au reboot en rajoutant la ligne:
<pre>
net.ipv6.conf.all.forwarding=1
</pre>
dans le fichier "/etc/sysctl.conf"
Cette option entraine aussi que votre VM ne s'autoconfigure plus en IPv6 (i.e. les lignes "pre-up" vues plus haut dans "/etc/network/interfaces" ne sont plus nécessaires).
Nous allons maintenant mettre en place une configuration automatique d'adresses IPv6 de toutes les machines du segment réseau partant du tap0 de la VM (soit le tap0 du client openvpn, mais après l'étape suivante toutes les interfaces de votre réseau local). Nous utiliserons pour celà l'outil radvd, avec le fichier de configuration /etc/radvd.conf:
<pre>
interface tap0
{
IgnoreIfMissing on;
AdvSendAdvert on;
AdvLinkMTU 1280;
prefix 2a01:6600:80XX:YY01::/64
{
AdvOnLink on;
AdvAutonomous on;
};
};
</pre>
+Remarque:+ le fichier contient le nom 'tap0' codé en dur, ce qui n'est pas portable. Par ailleurs, il est possible d'interdire à une machine de s'autoconfigurer, mais ce n'est pas le défaut pour Linux et j'ai supposé que vous ne l'avez pas modifié.
h3. Etape 5: bridger les interfaces réseau du client openvpn
A ce stade, la machine openvpn cliente peut accéder l'internet IPv6, car radvd aura placé une route par défaut via son tap0. Si vous bridgez maintenant ce tap0 avec son eth0 (normalement relié au reste de votre réseau local), toutes les machines de ce réseau local vont s'assigner au bout de quelques minutes une adresse tirée de la plage 2a01:6600:80XX:YY01::/64, et une route par défaut via le tap0 du client openvpn: c'est ce qu'on voulait obtenir.
Voici les incantations magiques nécessaires:
<pre>
# on suppose qu'eth0 a l'adresse 192.168.0.1/24
brctl addbr br0
brctl addif br0 eth0
brctl addif br0 tap0
# à ce stade, le machine hébergeant le client openvpn n'est plus adressable
# mais il est dans la plupart des cas utile de lui en redonner une, en général celle d'eth0
ip addr add 192.168.0.1/24 dev br0
</pre>
Il peut être intéressant de bridger par défaut eth0 et un tap0 prédéfini sur br0 dès le boot par une section de ce type dans /etc/network/interfaces:
<pre>
auto br0
iface br0 inet static
address 192.168.1.10
netmask 255.255.255.0
broadcast 192.168.0.255
gateway 192.168.1.1
bridge_ports eth0 tap0
pre-up tunctl -t tap0
</pre>
où la section 'iface br0' remplace 'iface eth0'.
Il faut ensuite modifier le configuration cliente /etc/openvpn/myris.conf comme suit:
<pre>
# on définit explicitement le tap0
dev tap0
proto udp
local ipv4-adresse-client-openvpn-domicile
remote 91.224.xx.yy
ca myris/ca.crt
cert myris/client.crt
key myris/client.key
tls-client
port 1194
ping 15
ping-restart 45
persist-tun
persist-key
# ifconfig et route ont disparus et sont remplacés par ce qui suit,
# qui fait la même chose appliqué à br0 et non pas tap0
script-security 3 system
up /etc/openvpn/myris-up.sh
down /etc/openvpn/myris-down.sh
</pre>
où /etc/openvpn/myris-up.sh vaut:
<pre>
#! /bin/sh
/sbin/ip addr add 10.0.0.1/30 dev br0
</pre>
et /etc/openvpn/myris-down.sh vaut:
<pre>
#! /bin/sh
/sbin/ip addr del 10.0.0.1/30 dev br0
</pre>
+Remarque:+ ne pas oublier de lancer:
<pre>
chmod 755 /etc/openvpn/myris-up.sh /etc/openvpn/myris-down.sh
</pre>
Il est à noter que l'apparition des adresses et routes IPv6 peut prendre un dizaine de minutes après l'établissemnt du tunnel openvpn, et de même leur disparation n'est complète qu'au bout de 24h. Tout celà est réglable via /etc/radvd.conf sur la VM.
h3. Etape 6: vie privée
Voir la section à ce sujet: [[IPv6#Protection-de-la-vie-privée]]
h2. IPv6 sous OpenWRT
Exemple pour un routeur OpenWRT connecté au réseau L2 de Tetaneutral (radio ou autre)
h3. Demander le routage du /56.
Il vous sera donné une IP link-locale sous la forme fe80::xx:yy .
h3. /etc/config/network
La définition du fichier network d'OpenWRT
<pre>
config 'interface' 'loopback'
option 'ifname' 'lo'
option 'proto' 'static'
option 'ipaddr' '127.0.0.1'
option 'netmask' '255.0.0.0'
config 'interface' 'wan_ttn'
option 'ifname' 'eth0.10'
option 'proto' 'static'
option 'ipaddr' '91.224.149.ZZ' # IPv4 publique
option 'netmask' '255.255.255.0'
option 'gateway' '91.224.149.254'
option 'dns' '91.224.149.254' # Le DNS ipv4 de TTN
option 'send_rs' '0' # Evite d'envoyer des annonces sur le réseau TTN
option 'accept_ra ' '0' # Refuse les routes diffusées par le réseau TTN
option 'ip6addr' 'fe80::XX:YY/64' # L'IP link-locale pour le routage
option 'ip6gw' 'fe80::31' # La gw IPv6 de TTN
config 'alias' # Alias pour l'IPv6 publique du routeur
option 'interface' 'wan_ttn'
option 'proto' 'static'
option 'ip6addr' '2a01:6600:8081:YY00::1/64'
config 'interface' 'lan' # Interface coté LAN
option 'proto' 'static'
option 'ifname' 'eth0.2'
option 'ipaddr' '192.168.1.254'
option 'netmask' '255.255.255.0'
option 'broadcast' '192.168.1.255'
option 'send_rs' '0'
option 'ip6addr' '2a01:6600:8081:YY02::1/64' # IP publique coté LAN
</pre>
h3. /etc/config/radvd
Ce fichier est très simple car OpenWRT calcule automatiquement les bonnes valeurs
à partir de la section "network" ci-dessus.
<pre>
config 'interface'
option 'AdvSendAdvert' '1'
option 'ignore' '0'
option 'interface' 'lan'
config 'prefix'
option 'ignore' '0'
option 'interface' 'lan'
config 'rdnss'
option 'interface' 'lan'
</pre>
à partir de là , le routeur diffuse des "Router Advertisement" sur son interface LAN et effectuera le routage.
Toute machine sur le réseau interne récupère ainsi une IP publique, addressable en direct.
h2. [[IPv6-ADSL | IPv6 sur ADSL et OpenWRT]]
h2. ip6tables
Via Philippe Latu du projet http://www.inetdoc.net/
<pre>
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# C H A I N E I N P U T
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# suivi de communication
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
# ICMPv6
-A INPUT -p icmpv6 -m state --state NEW -m limit --limit 5/sec -j ACCEPT
-A INPUT ! -i sixxs -p icmpv6 --icmpv6-type neighbour-solicitation -j ACCEPT
-A INPUT ! -i sixxs -p icmpv6 --icmpv6-type neighbour-advertisement -j
ACCEPT
# Filtrage paquets avec en-tête de routage de type 0
-A INPUT -m rt --rt-type 0 -j DROP
# Autorisation trafic multicast
-A INPUT -d ff00::/8 -j ACCEPT
# communication loopback
-A INPUT -i lo -m state --state NEW -j ACCEPT
# communication instances virtuelles
-A INPUT -i tap+ -m state --state NEW -j ACCEPT
# communication interne
-A INPUT -i bond0.+ -m state --state NEW -j ACCEPT
# SSH port 2222
-A INPUT -p tcp --syn --dport 2222 -m state --state NEW -j ACCEPT
# poubelle
-A INPUT -j LOG --log-prefix "INPUT/rejected.ip6tables: "
-A INPUT -m state --state INVALID -m limit --limit 5/min -j LOG --log-prefix "INPUT/invalid.ip6tables: "
-A INPUT -m state --state INVALID -j DROP
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# C H A I N E F O R W A R D
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# suivi de communication
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
# ICMPv6
-A FORWARD -p ipv6-icmp -m state --state NEW -m limit --limit 5/sec -j ACCEPT
# Filtrage paquets avec en-tête de routage de type 0
-A FORWARD -m rt --rt-type 0 -j DROP
# Autorisation trafic multicast
-A FORWARD -d ff00::/8 -j ACCEPT
# communication loopback
-A FORWARD -i lo -m state --state NEW -j ACCEPT
# communication instances virtuelles
-A FORWARD -i tap+ -m state --state NEW -j ACCEPT
# communication réseaux de TP
-A FORWARD -i bond0.+ -m state --state NEW -j ACCEPT
# poubelle
-A FORWARD -m state --state INVALID -m limit --limit 5/min -j LOG --log-prefix "INPUT/invalid.ip6tables: "
-A FORWARD -m state --state INVALID -j DROP
COMMIT
</pre>
h2. FAQ
h3. ipv6calc
<pre>
$ ipv6calc --in ipv6addr --out revnibbles.arpa 2a01:6600:8081:cf00::1
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.f.c.1.8.0.8.0.0.6.6.1.0.a.2.ip6.arpa.
$ ipv6calc --action geneui64 --in mac 00:22:4d:56:43:4e --out eui64
222:4dff:fe56:434e
</pre>
h3. Reverse DNS
En IPv6 tetaneutral.net peut deleguer le reverse du /56. Il faut configurer bind sur une ou plusieurs de vos machines, nous donner son CNAME, par exemple ns1.chezmoi.net et ns2.chezmoi.net, et mettre les fichiers suivant dans /etc/bind/ :
named.conf.local
<pre>
zone "1.8.0.8.0.0.6.6.1.0.a.2.ip6.arpa" {
type master;
file "/etc/bind/db.ip6-81";
};
</pre>
db.ip6-81
<pre>
; -*- mode: zone; -*-
;
; BIND reverse data file for broadcast zone
;
$TTL 3600
@ IN SOA ns1.tetaneutral.net. hostmaster.tetaneutral.net. (
2011070301 ; serial
7200 ; Refresh
3600 ; Retry
1800000 ; Expire
3600 ) ; Negative Cache TTL
@ IN NS ns1.tetaneutral.net.
@ IN NS ns2.tetaneutral.net.
; reverse
$ORIGIN 0.0.e.c.1.8.0.8.0.0.6.6.1.0.a.2.ip6.arpa.
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR www6.tetaneutral.net.
; delegations /56
$ORIGIN 1.8.0.8.0.0.6.6.1.0.a.2.ip6.arpa.
1.9 86400 IN NS hoersch.kneissel.org.
1.9 86400 IN NS serveur.kneissel.org.
e.8 86400 IN NS dns.kafe-in.net.
</pre>
Merci a Matthieu Herrb pour la délégation de reverse /56.
Coté utilisateur dans son bind :
Dans /etc/bind/named.conf.local
<pre>
zone "X.Y.1.8.0.8.0.0.6.6.1.0.a.2.ip6.arpa" {
type master;
file "/etc/bind/db.ip6-XY";
};
</pre>
/etc/bind/db.ip6-XY
<pre>
; -*- mode: zone; -*-
;
; BIND reverse data file for broadcast zone
;
$TTL 3600
@ IN SOA ns1.tetaneutral.net. hostmaster.tetaneutral.net. (
2011120700 ; serial
7200 ; Refresh
3600 ; Retry
1800000 ; Expire
3600 ) ; Negative Cache TTL
@ IN NS ns1.tetaneutral.net.
@ IN NS ns2.tetaneutral.net.
$ORIGIN 0.0.X.Y.1.8.0.8.0.0.6.6.1.0.a.2.ip6.arpa.
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR a1.tetaneutral.net.
2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR a2.tetaneutral.net.
3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR a3.tetaneutral.net.
</pre>
h3. CCNA et link-local
Merci à Jérôme Nicolle:
http://www.freeccnaworkbook.com/labs/section-12-configuring-ipv6/lab-12-3-configuring-ipv6-static-routing/
> Unlike IPv4 static routing, with IPv6 you have the ability to use either the global unicast address or link-local address as the next hop in the static route statement. When working with IPv6 dynamic routing protocols which will be discussed in the next 2 labs, the next hop will be the neighbors link-local IPv6 address and not their global unique assigned ipv6 address. However when configuring a static route with a link-local IPv6 address as the next hop you must specify the egress interface. For all intensive purposes, using either/or will achieve the same desired effect.
h3. Comment éviter d'utiliser une IPv6 non routée ?
Sur un IX en général les adresses sont non routées donc il faut éviter de les utiliser, pour cela on utilise "preferred_lft 0" :
http://www.davidc.net/networking/ipv6-source-address-selection-linux
<pre>
ip -6 a add 2001:7f8:59:0:75::15/96 dev eth0.502 preferred_lft 0
</pre>
Comment linux choisi une adresse IPv6 source https://www.kafe-in.net/articles/IPv6Source/
h3. Comment pinguer une addresse link local ?
<pre>
ping6 fe80::31%eth0
</pre>
h3. zones reverses ipv6 manquante dans bind (ie: ::1)
Dans bind par défaut les zones pour ::1 sont vide pour les ajouter:
<pre>
# cat /etc/bind/db.local-::.arpa
;
; BIND reverse data file for local loopback interface
;
$TTL 604800
@ IN SOA localhost. root.localhost. (
8 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS localhost.
1 IN PTR localhost.
</pre>
<pre>
# cat /etc/bind/db.local-::1.arpa
;
; BIND reverse data file for local loopback interface
;
$TTL 604800
@ IN SOA localhost. root.localhost. (
8 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS localhost.
@ IN PTR localhost.
</pre>
<pre>
# cat /etc/bind/named.conf.default-zones.v6
zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" IN {
type master;
file "/etc/bind/db.local-::.arpa";
};
zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" IN {
type master;
file "/etc/bind/db.local-::1.arpa";
};
</pre>
Et on ajoute ca dans /etc/bind/named.conf:
<pre>
include "/etc/bind/named.conf.default-zones.v6";
</pre>
h3. Envoie d'un Router Advertissement avec scapy pour virer une route auto apprise (Attention à n'utiliser que si on sait ce qu'on fait ! )
Création de trame ipv6, ipv6 src est celle du router à spoffer
<pre>
a = IPv6()
a.src = "fe80::dcad:4dff:fe0b:8a5"
a.dst = "ff02::1"
</pre>
La trame sera un RA avec un lifetime de 0, comme indiquer dans la rfc2461:
"Lifetime of 0 indicates that the router is not a default router and SHOULD NOT appear on the default router list."
<pre>
b = ICMPv6ND_RA()
b.routerlifetime = 0
</pre>
Ensuite on fixe la adresse MAC Ã spoofer, celle du router original qui a envoyer le RA.
<pre>
c = ICMPv6NDOptSrcLLAddr()
c.lladdr = "00:50:56:24:3b:c0"
</pre>
Ensuite on construire le contenu du RA, avec le prefix à annoncer (toujours celui à spoofer)
Avec le validlifetime et preferredlifetime à l'infinie, comme indiquer dans la rfc2461:
"A value of all one bits (0xffffffff) represents infinity"
<pre>
d = ICMPv6NDOptMTU()
e = ICMPv6NDOptPrefixInfo()
e.prefixlen = 64
e.prefix = "2a01:6600:8081:4300::"
e.validlifetime = 0xffffffff
e.preferredlifetime = 0xffffffff
</pre>
On envoie le tout:
<pre>
send(a/b/c/d/e)
</pre>
h3. PMTU
Try 'tracepath6' it will show you which hop is not returning a packet
too big for that path if needed. Also one can use a series of "ping6 -s
<size> -M do" to check if packets pass or not (if the destination allows
pings of course).
h2. IETF IPv6 security
From: Fernando Gont <fernando@gont.com.ar>
To: NANOG <nanog@nanog.org>
Subject: IPv6 security: New IETF I-Ds, slideware and videos of recent presentations, trainings, etc...
Date: Mon, 28 May 2012 22:17:33 -0300
Folks,
* We've published a new IETF I-D entitled "DHCPv6-Shield: Protecting
Against Rogue DHCPv6 Servers", which is meant to provide RA-Guard-like
protection against rogue DHCPv6 servers. The I-D is available at:
<http://tools.ietf.org/id/draft-gont-opsec-dhcpv6-shield-00.txt>
Other IPv6 security I-Ds (such as,
draft-ietf-v6ops-ra-guard-implementation) have been revised. Please
check them out at:
<http://www.si6networks.com/publications/ietf.html>
* The slideware (and some videos!) of some of our recent presentations
about IPv6 security are now available online. You can find them at:
<http://www.si6networks.com/presentations/index.html>
* We have also scheduled IPv6 hacking trainings in Paris (France) and
Ghent (Belgium). You can find more details at:
<http://www.si6networks.com/index.html#conferences>
Our Twitter: @SI6Networks
ipv6hackers mailing-list:
<http://lists.si6networks.com/listinfo/ipv6hackers/>
Thanks!
Best regards,
--
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
h2. Protection de la vie privée
h3. Le problème
En IPv6 en mode "autoconfiguration" (SLAAC) les derniers 64 bits de
l'adresse sont dérivés de manière réversible de la MAC de votre
interface. Si celle-ci est par exemple 00:0c:29:0c:47:d5, elle est
modifiée comme sur ce schéma:
!/attachments/125/Modified-EUI-64.png! !/attachments/124/Modified-EUI-64.png!
Si vous êtes chez vous derrière une freebox vous allez apparaître avec
2a01:e34:...:02:0c:29:ff:fe:0c:47:d5 dans les logs des serveurs auxquels
vous vous connectez et si vous allez ensuite à Myrys vous serez en
2a01:6600:8080:505:...::02:0c:29:ff:fe:0c:47:d5.
Donc tous ces serveurs, en regardant la fin de l'adresse IPv6, peuvent
déduire que vous êtes un freenaute qui va à Myrys, avec les heures et
tout, vos visites chez vos amis, hotspot, hôtels, et ce même si vous
avez desactivé les cookies pour la partie web, si vous utilisez https,
etc... C'est un danger pour la vie privée non présent en IPv4.
h3. Solutions
h4. Au niveau du routeur
* On peut bloquer l'émission des RA pour ne pas avoir d'adresse SLAAC
sur les machines du réseau concerné (c'est ce qui est fait à Tetaneutral
il me semble...). Et mettre en place un serveur DHCPv6 qui affecte les
adresses IPv6 soit dynamiquement à partir d'un pool soit de manière
statique (mais sans correspondance connue avec une adresse MAC).
* Selon la puissance d'expression du pare-feu on peut bloquer les
adresses SLAAC. Elles ont les 2 octets 'ff fe' aux positions 11 et 12
dans l'adresse IPv6.
h4. Au niveau du client
* Activer l'extension privacy si ce n'est pas le cas par défaut,
(RFC3041 remplacé par RFC4941). Une manière de faire sous Linux
Debian est d'avoir un script /etc/network/if-pre-up.d/ipv6 contenant:
<pre>
#! /bin/sh
echo 2 > /proc/sys/net/ipv6/conf/$IFACE/use_tempaddr
</pre>
Ne pas oublier de rendre executable:
<pre>
chmod 755 /etc/network/if-pre-up.d/ipv6
</pre>
La commande 'ip -6 a' donnera alors après quelques heures une sortie telle que:
<pre>
6: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
inet6 2a01:6600:1122:3344:bc01:d69e:cb4d:f3f0/64 scope global temporary dynamic
valid_lft 73784sec preferred_lft 1784sec
inet6 2a01:6600:1122:3344:40d7:48ee:af65:47f1/64 scope global temporary deprecated dynamic
valid_lft 59792sec preferred_lft 0sec
inet6 2a01:6600:1122:3344:d59d:1447:62ab:1f29/64 scope global temporary deprecated dynamic
valid_lft 45515sec preferred_lft 0sec
inet6 2a01:6600:1122:3344:2xx:yyff:fezz:ttww/64 scope global dynamic
valid_lft 86313sec preferred_lft 14313sec
inet6 fe80::2xx:yyff:fezz:ttww/64 scope link
valid_lft forever preferred_lft forever
</pre>
où 00:xx:yy:zz:tt:ww est l'adresse MAC de l'interface (ici un bridge
qui prend l'adresse MAC de la première interface physique qui lui est
connectée). Les adresses 'deprecated' ne sont là que pour permettre
aux connexions démarrées durant leur durée de validité de
s'achever. Les nouvelles connexions utilisent la première adresse qui
a encore 1784 secondes de durée de vie restante.
* Modifier l'adresse MAC a chaque connexion
(OpenBSD propose 'ifconfig <if> lladdr random' pour cela :-)
* Bloquer avec le pare-feu local les paquets contenant l'adresse
SLAAC si possible.
Si les adresses IPv6 sont affectéees par un serveur DHCPv6 elles ne
sont normalement pas liées à l'adresse MAC.
h4. Liens
* http://www.rfc-editor.org/rfc/rfc4941.txt Le RFC sur les privacy extensions
* http://superuser.com/questions/243669/how-to-avoid-exposing-my-mac-address-when using-ipv6
* https://home.regit.org/2011/04/ipv6-privacy/ IPv6 privacy extensions on Linux
* http://www.queret.net/blog/2012/04/357/ IPv6: Ubuntu 12.04 active la RFC4941 (Privacy Extensions) par default
* http://support.menandmice.com/jforum/posts/list/219.page Enable Privacy extensions on Mac OS X 10.5 and 10.6
* http://tools.ietf.org/html/draft-ietf-6man-stable-privacy-addresses-01
h3. Mais...
Cela dit, il a été montré qu'il y a plein d'autres moyens pour les
sites web qui veulent traquer leurs utilisateurs de collecter des
informations discriminantes sur ceux-ci (type de navigateur,
extensions installées,...):
http://news.cnet.com/8301-1009_3-20005185-83.html
http://www.scatmania.org/2012/04/24/visitor-tracking-without-cookies/
h1. IPv6
Déploiement a tetaneutral.net : #35
h2. Liens
[[WorldIPv6Launch20120606]]
General
* http://en.wikipedia.org/wiki/ICMPv6
* http://en.wikipedia.org/wiki/Neighbor_Discovery_Protocol
* http://en.wikipedia.org/wiki/Radvd
* http://en.wikipedia.org/wiki/DHCPv6
** https://wikispaces.psu.edu/display/ipv6/DHCPv6
* http://www.iana.org/assignments/icmpv6-parameters
Statistics
* http://bgp.he.net/ipv6-progress-report.cgi
* https://labs.ripe.net/Members/mirjam/content-ipv6-measurement-compilation
* http://www.ripe.net/internet-coordination/ipv4-exhaustion/ipv4-available-pool-graph
* http://www.google.com/ipv6/statistics.html
* http://julien.vaubourg.com/files/lothaire-yarding_ipv6.pdf
* https://www.ams-ix.net/technical/statistics/sflow-stats/ipv6-traffic
Linux
* http://madduck.net/docs/ipv6/
* http://tldp.org/HOWTO/Linux+IPv6-HOWTO/
* http://linux.die.net/man/8/rdisc6
* bind IPv4+IPv6 /proc/sys/net/ipv6/bindv6only http://www.kernel.org/doc/man-pages/online/pages/man7/ipv6.7.html
* sileht : comme arpwatch mais en ipv6 http://ndpmon.sourceforge.net/
* sileht : proxy NDP auto http://www.priv.nu/projects/ndppd/ et https://github.com/Tuhox/ndppd
* dachary : hairpin_mode issue nova https://bugs.launchpad.net/nova/+bug/1011134
* https://wiki.archlinux.org/index.php/IPv6
Tunnels
* http://en.wikipedia.org/wiki/List_of_IPv6_tunnel_brokers
* http://tunnelbroker.net
* http://sonic.net/features/ipv6/
Misc
* Cool IPv6 stuff http://www.sixxs.net/misc/coolstuff/
* http://interviews.slashdot.org/story/11/10/25/1532213/vint-cerf-answers-your-questions-about-ipv6-and-more
* http://infosecblog.antonaylward.com/2010/08/05/re-opensuse-ipv6-nat-was-113-and-ssh-x-forwarding-not-working/
* conférence JRES 2011 http://stream.ut-capitole.fr/jres2011/57.html
* http://vincent.riquer.fr/blog/archives/2010/04/11/openvpn__ipv6__bind__happiness/index.html
* http://blog.si6networks.com/2012/02/ipv6-nids-evasion-and-improvements-in.html
* https://vador.fdn.fr/wiki/support:faq:ipv6
* http://blog.si6networks.com/2012/02/ipv6-nids-evasion-and-improvements-in.html
* http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-first_hop_security.html#wp1054246
* http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard-implementation-01
* http://www.ripe.net/lir-services/training/material/IPv6-for-LIRs-Training-Course/IPv6_addr_plan4.pdf
Opérateurs
* DS-Lite chez FT http://www.ietf.org/mail-archive/web/v6ops/current/msg10652.html
* IPv6 chez comcast http://tech.slashdot.org/story/11/11/09/174217/comcast-begins-native-ipv6-deployment-to-end-users
* DHCP-PD http://ipv6.internode.on.net/
* Ninux [[AirOS]] vs [[OpenWRT]] retour d'experience http://blog.ninux.org/2012/06/06/the-ipv6-deployment-in-the-ninux-community-network/
Tests
* http://ip6.nl/
h2. RIPE
* IPv6 Address Allocation and Assignment Policy
** http://www.ripe.net/ripe/docs/ripe-552
* RIPE Routing Working Group Recommendations on IPv6 Route Aggregation
** http://www.ripe.net/ripe/docs/ripe-532
h2. Configuration d'un LAN « IPv6 only » sous debian
* [[NAT64DNS64]]
* [[THSF 2012]]
h2. Debian
* http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=643594
** ebtables: v2.0.10-1 wish for ipv6-icmp and security
** fixé le 5 juin 2012
** voir aussi [[Spoofing]]
h2. Discovery
RFC4291 https://tools.ietf.org/html/rfc4291
Pinging the multicast address ff02::1 results in all hosts in link-local scope responding. An interface has to be specified. With a ping to the multicast address ff02::2 only routers will respond.
If you add an option -I <your-global-ipv6>, link-local hosts will respond with their link-global scope addresses.
h2. Désactiver la configuration automatique
http://lists.tetaneutral.net/pipermail/technique/2011-November/000086.html
Un serveur aura typiquement une configuration entièrement statique assignée par l'hébergeur, laisser la configuration dynamique activée est un risque de voir un tiers prendre le controle du routage serveur ou l'empécher de fonctionner via l'envoi d'une configuration dynamique erronée. Il est donc préférable de désactiver la configuration dynamique IPv6 sur une VM ou serveur physique hébergé chez tetaneutral.net. Si votre VM est en mode routeur (c'est à dire la commande "more /proc/sys/net/ipv6/conf/all/forwarding" renvoit 1), cette désactivation est implicite, voir dans le source du noyau Linux le fichier "Documentation/networking/ip-sysctl.txt")
En version rapide executer sur sa VM ou machine en root la ligne suivante :
<pre>
wget -qO - http://tetaneutral.net/ipv6/ipv6noauto.sh | bash
</pre>
Le détail de ce que fait ce script ci-après.
h3. Désactiver autoconf et accept_ra pour la session en cours
Executer en root la ligne suivante :
<pre>
for i in /proc/sys/net/ipv6/conf/*; do for j in autoconf accept_ra; do echo 0 > $i/$j; done;done
</pre>
h3. Le rendre permanent en cas de reboot
Editer la section inte6 de /etc/network/interfaces pour ajouter deux "pre-up" entre la ligne "iface" et la ligne "address" :
<pre>
iface eth0 inet6 static
pre-up echo 0 > /proc/sys/net/ipv6/conf/$IFACE/accept_ra
pre-up echo 0 > /proc/sys/net/ipv6/conf/$IFACE/autoconf
address ...
</pre>
Créer un fichier pour sysctl :
<pre>
cat > /etc/sysctl.d/local-ipv6.conf <<EOF
# No IPV6 RA or autoconf
net.ipv6.conf.all.autoconf = 0
net.ipv6.conf.all.accept_ra = 0
net.ipv6.conf.default.autoconf = 0
net.ipv6.conf.default.accept_ra = 0
EOF
</pre>
h3. Référence : source du script ipv6noauto.sh
<pre>
echo deactivating autoconf and accept_ra
for i in /proc/sys/net/ipv6/conf/*; do
for j in autoconf accept_ra; do
echo $i/$j
echo 0 > $i/$j
done
done
F=/etc/network/interfaces
if ! grep accept_ra $F >& /dev/null; then
echo fixing /etc/network/interfaces
cp -f $F $F.save
sed -e 's,iface eth0 inet6 static,iface eth0 inet6 static\n pre-up echo 0 > /proc/sys/net/ipv6/conf/$IFACE/accept_ra\n pre-up echo 0 > /proc/sys/net/ipv6/conf/$IFACE/autoconf,g' < $F.save > $F
fi
if [ ! -f /etc/sysctl.d/local-ipv6.conf ]; then
echo creating /etc/sysctl.d/local-ipv6.conf
cat > /etc/sysctl.d/local-ipv6.conf <<EOF
# No IPV6 RA or autoconf
net.ipv6.conf.all.autoconf = 0
net.ipv6.conf.all.accept_ra = 0
net.ipv6.conf.default.autoconf = 0
net.ipv6.conf.default.accept_ra = 0
EOF
fi
echo done
</pre>
h2. ARP cache limits
TODO via Cyril B.
<pre>
net.ipv6.neigh.default.gc_thresh1 = 1024
net.ipv6.neigh.default.gc_thresh2 = 2048
net.ipv6.neigh.default.gc_thresh3 = 4096
</pre>
h2. Pièges
Attention a bien mettre les zéros en fin de mot :
Ne pas mettre 2a01:6600:8081:XX:: car c'est 2a01:6600:8081: *00* XX::
Utiliser 2a01:6600:8081: *XX00* ::
h2. Comment activer le routage sur son /56 IPv6 ?
Chaque IPv4 livrée par tetaneutral.net est associé à un /56 IPv6, avec une équivalence /24 = 256 IPv4 <=> /48 = 256 /56 IPv6
h2. Discussions
> J'ai fait quelques essais: VM configuré en routeur, openvpn entre la VM
> et ma machine, histoire de simuler des interfaces. J'ai essayé radvd
> comme des définitions manuelles des adresses IPv6.
>
> Bon, ça marche depuis la VM mais pas depuis chez moi (wget
> http://ipv6.google.com), même si les paquets IPv6 (vu avec tcpdump)
> partent bien de la VM vers l'internet. Mais il n'y a pas de retour.
>
> Après quelques cogitations et la lecture de ceci:
> http://www.fdn.fr/IPv6-a-la-maison.html j'en arrive à ces
> réflexions:
>
> 1) Dans le blog FDN ci-dessus l'adresse IPv6 affectée au ppp0 n'est pas
> dans son /48; ce qui voudrait dire qu'il n'y a pas de raison d'affecter
> une IPv6 du /56 au eth0 des VM tetaneutral.
>
> 2) Pour faire marcher une telle config à FDN, le routeur FDN en amont du
> modem/routeur de l'abonné devrait avoir une route du type:
> ip -6 route add range/48 dev ppp-abonné via link-local-ppp-abonné
> soit chez nous:
> ip -6 route add range/56 dev eth0-vm via link-local-eth0-vm
>
> > du /56 via une interconnection explicite entre le routeur de
> > tetaneutral.net et un routeur chez le membre ?
>
> Un lien openvpn?
Bonsoir,
On peut rajouter une regle de routage comme tu le suggere,
reste a choisir les details pratiques.
Pour la link-local coté routeur on a choisi fe80::31 en statique il
reste a choisir une regle pour attribuer le link local coté client.
Une regle automatique basée sur l'IPv4 est en place pour
l'attribution du subnet IPv6 :
http://wiki.tetaneutral.net/index.php/Architecture
Une regle similaire pour le routage donnerait par exemple fe80::81:XY
ou XY est le dernier octet de l'IPv4 ecrit en hexadecimal
pour la link local coté client.
L'avantage d'une regle statique vs le SLAAC c'est que c'est un peu plus
flexible coté client sur le choix de l'equipement routeur.
L'avantage du routé est bien sur la flexibilité et la sécurisation
potentielle, l'inconvenient est qu'avec nos equipements actuels peu
puissant on perdra un peu en debit mais ça se corrigera avec
de nouveaux equipements.
Je suis vraiment curieux de savoir comment font les autres hebergeurs
dans le monde IPv6, ceux auxquels j'ai acces ne proposent pas de
routage, simplement ce que propose tetaneutral.net actuellement.
Suggestions ?
h2. Connectivité IPv6 complète depuis chez vous en quelques étapes simples
Connectivité complète signifie que toutes vos machines pouvant fonctionner en IPv6 peuvent accéder des sites IPv6 externes mais surtout être joignables de l'extérieur sur une adresse IPv6 propre. Pas de NAT ou autre bidouille de ce genre. Implications en terme d'autohébergement et sécurité laissées en exercice.
Pour bien comprendre ce qui suit, il est recommandé d'avoir un peu potassé les hyperliens plus haut et mieux encore d'avoir joué avec l'IPv6 sur votre réseau local maison en utilisant par exemple des adresses ULA.
h3. Etape 1: obtenir une machine virtuelle Tetaneutral.
Celle-ci (on l'appellera VM dans la suite) sera configurée par défaut comme suit dans /etc/network/interfaces du point de vue IPv6:
<pre>
iface eth0 inet6 static
# les 2 lignes qui suivent ne seront pas nécessaires lorsque
# plus loin nous passerons en mode routeur
pre-up echo 0 > /proc/sys/net/ipv6/conf/$IFACE/accept_ra
pre-up echo 0 > /proc/sys/net/ipv6/conf/$IFACE/autoconf
address 2a01:6600:80XX:YY00::1
netmask 56
gateway fe80::31
</pre>
où XX et YY sont les versions hexadécimales des xx et yy décimaux de votre (unique!) adresse IPv4 de la forme 91.224.xx.yy.
Voyons ce qu'implique la prise en compte par le système de ce fragment de /etc/network/interfaces. Il dit que:
# l'adresse 2a01:6600:80XX:YY00::1 est affectée à eth0, ce qui signifie que votre VM est accessible à cette adresse depuis l'intérieur de la VM comme depuis l'extérieur par toutes les machines du même segment réseau que eth0
# les paquets passant par votre VM peuvent atteindre les adresses de la plage 2a01:6600:80XX:YY00::/56 en étant envoyés en sortie de l'interface eth0
La plage 2a01:6600:80XX:YY00::/56 a été allouée par tetaneutral à votre VM. Notre problème est d'allouer une partie de ces adresses à des machines de notre domicile en utilisant l'accès que nous avons (en IPv4!) à la VM.
Avec cette configuration, vous pouvez héberger sur la VM des milliards de serveurs avec des adresses IPv6 différentes, il suffit de les ajouter à eth0 par une commande du type:
<pre>
ip -6 address add une-adresse-ipv6-de-votre-plage/56 dev eth0
</pre>
Le /56 n'est pas absolument nécessaire, il évite juste de rajouter une route plus spécifique pour atteindre votre nouvelle adresse IPv6 depuis votre VM, route qui s'avère redondante.
Le lecteur attentif aura noté que cette configuration déclare que toutes les adresses de votre plage sont situées derrière eth0, en dehors de la partie contrôlée par votre VM, et il semble impossible alors d'en distraire une partie. Il y a au moins deux solutions à ce problème:
# S'arranger pour que les segments réseau de votre domicile fassent partie de celui partant de eth0 sur la VM. Celà revient techniquement à bridger ces segments réseaux. Cette solution a cependant des inconvénients en terme de configurabilité et de sécurité.
# Réduire la plage IPv6 allouée derrière l'eth0 de la VM et réallouer le solde à votre réseau local maison, par des techniques de routage. C'est ce qu'on va décrire dans la suite. Mais d'abord, on a besoin d'un peu de collaboration de Tetaneutral.
h3. Etape 2: faire router votre plage /56 par Tetaneutral.
Dans la configuration par défaut des VM Tetaneutral, l'hôte des VM crée la route vers l'adresse 2a01:6600:80XX:YY00::1 (et des autres que vous rajoutez éventuellement à la main sur eth0) par l'utilisation de l'équivalent IPv6 d'ARP. Il est donc impossible de router vers une adresse qui n'existe pas sur cet eth0.
Tetaneutral doit donc rajouter une route explicite:
<pre>
ip -6 route add 2a01:6600:80XX:YY00::/56 via fe80::XX:YY dev votre-eth0-côté-hôte
</pre>
Celà n'a de sens que si fe80::XX:YY une des adresses de l'eth0 côté VM. Il faut donc l'ajouter et le mieux est de le faire via une directive 'up' dans /etc/network/interfaces:
<pre>
iface eth0 inet6 static
# les 2 lignes qui suivent ne seront pas nécessaires lorsque
# plus loin nous passerons en mode routeur
pre-up echo 0 > /proc/sys/net/ipv6/conf/$IFACE/accept_ra
pre-up echo 0 > /proc/sys/net/ipv6/conf/$IFACE/autoconf
address 2a01:6600:80XX:YY00::1
netmask 64
gateway fe80::31
up ip -6 add add fe80::XX:YY dev eth0
</pre>
Mon lecteur toujours très attentif n'aura pas manqué de noter que netmask ci-dessus est passé de 56 à 64. Nous n'allouons donc maintenant plus toutes nos adresses IPv6 sur le segment réseau partant d'eth0. En particulier, nous allons voir maintenant comment récupérer la sous-plage 2a01:6600:80XX:YY01::/64 pour notre réseau à domicile.
+Remarque:+ la sous-plage doit être /64, sinon l'adressage automatique des interfaces réseau qu'on verra plus loin ne marchera pas.
h3. Etape 3: simuler un lien ethernet entre une machine à domicile et cette VM.
Les technologies VPN/tunnel sont le pendant réseau des machines virtuelles: elles permettent de créer des interfaces réseaux virtuelles (du point de vue hardware, mais bien réelles d'un point de vue logiciel) et de les connecter entre elles.
Tout comme les machines virtuelles nécessitent quand même un minimum de support silicium, un VPN/tunnel va nécessiter de s'appuyer sur une vraie liaison entre deux vraies interfaces réseau, en l'occurence pour nous la liaison internet IPv4 entre autre utilisée pour l'administration de la VM depuis votre domicile. Plus précisément, nous allons utiliser l'outil openvpn.
La première étape va consister à installer openvpn en mode serveur sur la VM. Le fichier suivant est à créer dans /etc/openvpn/myris.conf:
<pre>
dev tap
proto udp
local 91.224.xx.yy
float
ca myris/ca.crt
cert myris/myris.crt
key myris/myris.key
dh myris/dh1024.pem
tls-server
port 1194
ping 15
ping-restart 45
# car serveur
ping-timer-rem
persist-tun
persist-key
ifconfig 10.0.0.2 255.255.255.252
route ipv4-adresse-client-openvpn-domicile 255.255.255.255 10.0.0.1
script-security 3 system
route-up "/sbin/ip -6 addr add 2a01:6600:80XX:YY01::1/64 dev tap0"
</pre>
+Remarque:+ le paramètre route-up contient le nom 'tap0' codé en dur, ce qui n'est pas portable. Cette commande est nécessaire pour créer sur la VM une route vers la bonne interface pour la plage 2a01:6600:80XX:YY01::/64. Pour que le serveur openvpn soit toujours présent, il faut ajouter
<pre>
AUTOSTART="myris"
</pre>
à /etc/default/openvpn.
Sur la machine à domicile, il faut une installation en mode client, pourquoi pas le même nom de fichier que le serveur, mais pas le même contenu:
<pre>
dev tap
proto udp
local ipv4-adresse-client-openvpn-domicile
remote 91.224.xx.yy
ca myris/ca.crt
cert myris/client.crt
key myris/client.key
tls-client
port 1194
ping 15
ping-restart 45
persist-tun
persist-key
ifconfig 10.0.0.1 255.255.255.252
route 0.0.0.0 0.0.0.0 10.0.0.2
</pre>
L'adresse ipv4-adresse-client-openvpn-domicile est toute adresse qui permet d'accéder Internet depuis la machine accueillant l'openvpn client; en général, ce ne sera donc pas votre adresse IP externe allouée par votre FAI, elle sera plutôt du genre 192.168.*.*. ou 10.*.*.*. Il est supposé bien sûr dans l'exemple ci-dessus que vous n'utilisez pas 10.0.0.0/30 chez vous, elle a été réservée au lien openvpn.
Les répertoires /etc/openvpn/myris sur VM et machine cliente contiendront les divers certificats et clés, qu'il faut générer. Voici comment faire:
<pre>
cd un-répertoire de travail
cp -R /usr/share/doc/openvpn/examples/easy-rsa/2.0/ .
cd 2.0
# Editez à votre convenance les 5 dernières variables d'environnement de type KEY_* du fichier vars
source ./vars
./clean-all
./build-dh
./pkitool --initca
./pkitool --server myris
./pkitool client
</pre>
et les fichiers recherchés se trouvent dans le sous-répertoire keys. Le seul fichier commun aux 2 extrémités du lien openvpn est ca.crt.
h3. Etape 4: passer la VM en mode routeur et annoncer des routes pour votre réseau à domicile avec radvd.
Pour autoriser les paquets à être routés sur la VM entre eth0 et tap0, il faut passer en mode routeur:
<pre>
echo 1 >/proc/sys/net/ipv6/conf/all/forwarding
</pre>
Il est encore mieux de conserver ce mode au reboot en rajoutant la ligne:
<pre>
net.ipv6.conf.all.forwarding=1
</pre>
dans le fichier "/etc/sysctl.conf"
Cette option entraine aussi que votre VM ne s'autoconfigure plus en IPv6 (i.e. les lignes "pre-up" vues plus haut dans "/etc/network/interfaces" ne sont plus nécessaires).
Nous allons maintenant mettre en place une configuration automatique d'adresses IPv6 de toutes les machines du segment réseau partant du tap0 de la VM (soit le tap0 du client openvpn, mais après l'étape suivante toutes les interfaces de votre réseau local). Nous utiliserons pour celà l'outil radvd, avec le fichier de configuration /etc/radvd.conf:
<pre>
interface tap0
{
IgnoreIfMissing on;
AdvSendAdvert on;
AdvLinkMTU 1280;
prefix 2a01:6600:80XX:YY01::/64
{
AdvOnLink on;
AdvAutonomous on;
};
};
</pre>
+Remarque:+ le fichier contient le nom 'tap0' codé en dur, ce qui n'est pas portable. Par ailleurs, il est possible d'interdire à une machine de s'autoconfigurer, mais ce n'est pas le défaut pour Linux et j'ai supposé que vous ne l'avez pas modifié.
h3. Etape 5: bridger les interfaces réseau du client openvpn
A ce stade, la machine openvpn cliente peut accéder l'internet IPv6, car radvd aura placé une route par défaut via son tap0. Si vous bridgez maintenant ce tap0 avec son eth0 (normalement relié au reste de votre réseau local), toutes les machines de ce réseau local vont s'assigner au bout de quelques minutes une adresse tirée de la plage 2a01:6600:80XX:YY01::/64, et une route par défaut via le tap0 du client openvpn: c'est ce qu'on voulait obtenir.
Voici les incantations magiques nécessaires:
<pre>
# on suppose qu'eth0 a l'adresse 192.168.0.1/24
brctl addbr br0
brctl addif br0 eth0
brctl addif br0 tap0
# à ce stade, le machine hébergeant le client openvpn n'est plus adressable
# mais il est dans la plupart des cas utile de lui en redonner une, en général celle d'eth0
ip addr add 192.168.0.1/24 dev br0
</pre>
Il peut être intéressant de bridger par défaut eth0 et un tap0 prédéfini sur br0 dès le boot par une section de ce type dans /etc/network/interfaces:
<pre>
auto br0
iface br0 inet static
address 192.168.1.10
netmask 255.255.255.0
broadcast 192.168.0.255
gateway 192.168.1.1
bridge_ports eth0 tap0
pre-up tunctl -t tap0
</pre>
où la section 'iface br0' remplace 'iface eth0'.
Il faut ensuite modifier le configuration cliente /etc/openvpn/myris.conf comme suit:
<pre>
# on définit explicitement le tap0
dev tap0
proto udp
local ipv4-adresse-client-openvpn-domicile
remote 91.224.xx.yy
ca myris/ca.crt
cert myris/client.crt
key myris/client.key
tls-client
port 1194
ping 15
ping-restart 45
persist-tun
persist-key
# ifconfig et route ont disparus et sont remplacés par ce qui suit,
# qui fait la même chose appliqué à br0 et non pas tap0
script-security 3 system
up /etc/openvpn/myris-up.sh
down /etc/openvpn/myris-down.sh
</pre>
où /etc/openvpn/myris-up.sh vaut:
<pre>
#! /bin/sh
/sbin/ip addr add 10.0.0.1/30 dev br0
</pre>
et /etc/openvpn/myris-down.sh vaut:
<pre>
#! /bin/sh
/sbin/ip addr del 10.0.0.1/30 dev br0
</pre>
+Remarque:+ ne pas oublier de lancer:
<pre>
chmod 755 /etc/openvpn/myris-up.sh /etc/openvpn/myris-down.sh
</pre>
Il est à noter que l'apparition des adresses et routes IPv6 peut prendre un dizaine de minutes après l'établissemnt du tunnel openvpn, et de même leur disparation n'est complète qu'au bout de 24h. Tout celà est réglable via /etc/radvd.conf sur la VM.
h3. Etape 6: vie privée
Voir la section à ce sujet: [[IPv6#Protection-de-la-vie-privée]]
h2. IPv6 sous OpenWRT
Exemple pour un routeur OpenWRT connecté au réseau L2 de Tetaneutral (radio ou autre)
h3. Demander le routage du /56.
Il vous sera donné une IP link-locale sous la forme fe80::xx:yy .
h3. /etc/config/network
La définition du fichier network d'OpenWRT
<pre>
config 'interface' 'loopback'
option 'ifname' 'lo'
option 'proto' 'static'
option 'ipaddr' '127.0.0.1'
option 'netmask' '255.0.0.0'
config 'interface' 'wan_ttn'
option 'ifname' 'eth0.10'
option 'proto' 'static'
option 'ipaddr' '91.224.149.ZZ' # IPv4 publique
option 'netmask' '255.255.255.0'
option 'gateway' '91.224.149.254'
option 'dns' '91.224.149.254' # Le DNS ipv4 de TTN
option 'send_rs' '0' # Evite d'envoyer des annonces sur le réseau TTN
option 'accept_ra ' '0' # Refuse les routes diffusées par le réseau TTN
option 'ip6addr' 'fe80::XX:YY/64' # L'IP link-locale pour le routage
option 'ip6gw' 'fe80::31' # La gw IPv6 de TTN
config 'alias' # Alias pour l'IPv6 publique du routeur
option 'interface' 'wan_ttn'
option 'proto' 'static'
option 'ip6addr' '2a01:6600:8081:YY00::1/64'
config 'interface' 'lan' # Interface coté LAN
option 'proto' 'static'
option 'ifname' 'eth0.2'
option 'ipaddr' '192.168.1.254'
option 'netmask' '255.255.255.0'
option 'broadcast' '192.168.1.255'
option 'send_rs' '0'
option 'ip6addr' '2a01:6600:8081:YY02::1/64' # IP publique coté LAN
</pre>
h3. /etc/config/radvd
Ce fichier est très simple car OpenWRT calcule automatiquement les bonnes valeurs
à partir de la section "network" ci-dessus.
<pre>
config 'interface'
option 'AdvSendAdvert' '1'
option 'ignore' '0'
option 'interface' 'lan'
config 'prefix'
option 'ignore' '0'
option 'interface' 'lan'
config 'rdnss'
option 'interface' 'lan'
</pre>
à partir de là , le routeur diffuse des "Router Advertisement" sur son interface LAN et effectuera le routage.
Toute machine sur le réseau interne récupère ainsi une IP publique, addressable en direct.
h2. [[IPv6-ADSL | IPv6 sur ADSL et OpenWRT]]
h2. ip6tables
Via Philippe Latu du projet http://www.inetdoc.net/
<pre>
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# C H A I N E I N P U T
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# suivi de communication
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
# ICMPv6
-A INPUT -p icmpv6 -m state --state NEW -m limit --limit 5/sec -j ACCEPT
-A INPUT ! -i sixxs -p icmpv6 --icmpv6-type neighbour-solicitation -j ACCEPT
-A INPUT ! -i sixxs -p icmpv6 --icmpv6-type neighbour-advertisement -j
ACCEPT
# Filtrage paquets avec en-tête de routage de type 0
-A INPUT -m rt --rt-type 0 -j DROP
# Autorisation trafic multicast
-A INPUT -d ff00::/8 -j ACCEPT
# communication loopback
-A INPUT -i lo -m state --state NEW -j ACCEPT
# communication instances virtuelles
-A INPUT -i tap+ -m state --state NEW -j ACCEPT
# communication interne
-A INPUT -i bond0.+ -m state --state NEW -j ACCEPT
# SSH port 2222
-A INPUT -p tcp --syn --dport 2222 -m state --state NEW -j ACCEPT
# poubelle
-A INPUT -j LOG --log-prefix "INPUT/rejected.ip6tables: "
-A INPUT -m state --state INVALID -m limit --limit 5/min -j LOG --log-prefix "INPUT/invalid.ip6tables: "
-A INPUT -m state --state INVALID -j DROP
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# C H A I N E F O R W A R D
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# suivi de communication
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
# ICMPv6
-A FORWARD -p ipv6-icmp -m state --state NEW -m limit --limit 5/sec -j ACCEPT
# Filtrage paquets avec en-tête de routage de type 0
-A FORWARD -m rt --rt-type 0 -j DROP
# Autorisation trafic multicast
-A FORWARD -d ff00::/8 -j ACCEPT
# communication loopback
-A FORWARD -i lo -m state --state NEW -j ACCEPT
# communication instances virtuelles
-A FORWARD -i tap+ -m state --state NEW -j ACCEPT
# communication réseaux de TP
-A FORWARD -i bond0.+ -m state --state NEW -j ACCEPT
# poubelle
-A FORWARD -m state --state INVALID -m limit --limit 5/min -j LOG --log-prefix "INPUT/invalid.ip6tables: "
-A FORWARD -m state --state INVALID -j DROP
COMMIT
</pre>
h2. FAQ
h3. ipv6calc
<pre>
$ ipv6calc --in ipv6addr --out revnibbles.arpa 2a01:6600:8081:cf00::1
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.f.c.1.8.0.8.0.0.6.6.1.0.a.2.ip6.arpa.
$ ipv6calc --action geneui64 --in mac 00:22:4d:56:43:4e --out eui64
222:4dff:fe56:434e
</pre>
h3. Reverse DNS
En IPv6 tetaneutral.net peut deleguer le reverse du /56. Il faut configurer bind sur une ou plusieurs de vos machines, nous donner son CNAME, par exemple ns1.chezmoi.net et ns2.chezmoi.net, et mettre les fichiers suivant dans /etc/bind/ :
named.conf.local
<pre>
zone "1.8.0.8.0.0.6.6.1.0.a.2.ip6.arpa" {
type master;
file "/etc/bind/db.ip6-81";
};
</pre>
db.ip6-81
<pre>
; -*- mode: zone; -*-
;
; BIND reverse data file for broadcast zone
;
$TTL 3600
@ IN SOA ns1.tetaneutral.net. hostmaster.tetaneutral.net. (
2011070301 ; serial
7200 ; Refresh
3600 ; Retry
1800000 ; Expire
3600 ) ; Negative Cache TTL
@ IN NS ns1.tetaneutral.net.
@ IN NS ns2.tetaneutral.net.
; reverse
$ORIGIN 0.0.e.c.1.8.0.8.0.0.6.6.1.0.a.2.ip6.arpa.
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR www6.tetaneutral.net.
; delegations /56
$ORIGIN 1.8.0.8.0.0.6.6.1.0.a.2.ip6.arpa.
1.9 86400 IN NS hoersch.kneissel.org.
1.9 86400 IN NS serveur.kneissel.org.
e.8 86400 IN NS dns.kafe-in.net.
</pre>
Merci a Matthieu Herrb pour la délégation de reverse /56.
Coté utilisateur dans son bind :
Dans /etc/bind/named.conf.local
<pre>
zone "X.Y.1.8.0.8.0.0.6.6.1.0.a.2.ip6.arpa" {
type master;
file "/etc/bind/db.ip6-XY";
};
</pre>
/etc/bind/db.ip6-XY
<pre>
; -*- mode: zone; -*-
;
; BIND reverse data file for broadcast zone
;
$TTL 3600
@ IN SOA ns1.tetaneutral.net. hostmaster.tetaneutral.net. (
2011120700 ; serial
7200 ; Refresh
3600 ; Retry
1800000 ; Expire
3600 ) ; Negative Cache TTL
@ IN NS ns1.tetaneutral.net.
@ IN NS ns2.tetaneutral.net.
$ORIGIN 0.0.X.Y.1.8.0.8.0.0.6.6.1.0.a.2.ip6.arpa.
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR a1.tetaneutral.net.
2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR a2.tetaneutral.net.
3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR a3.tetaneutral.net.
</pre>
h3. CCNA et link-local
Merci à Jérôme Nicolle:
http://www.freeccnaworkbook.com/labs/section-12-configuring-ipv6/lab-12-3-configuring-ipv6-static-routing/
> Unlike IPv4 static routing, with IPv6 you have the ability to use either the global unicast address or link-local address as the next hop in the static route statement. When working with IPv6 dynamic routing protocols which will be discussed in the next 2 labs, the next hop will be the neighbors link-local IPv6 address and not their global unique assigned ipv6 address. However when configuring a static route with a link-local IPv6 address as the next hop you must specify the egress interface. For all intensive purposes, using either/or will achieve the same desired effect.
h3. Comment éviter d'utiliser une IPv6 non routée ?
Sur un IX en général les adresses sont non routées donc il faut éviter de les utiliser, pour cela on utilise "preferred_lft 0" :
http://www.davidc.net/networking/ipv6-source-address-selection-linux
<pre>
ip -6 a add 2001:7f8:59:0:75::15/96 dev eth0.502 preferred_lft 0
</pre>
Comment linux choisi une adresse IPv6 source https://www.kafe-in.net/articles/IPv6Source/
h3. Comment pinguer une addresse link local ?
<pre>
ping6 fe80::31%eth0
</pre>
h3. zones reverses ipv6 manquante dans bind (ie: ::1)
Dans bind par défaut les zones pour ::1 sont vide pour les ajouter:
<pre>
# cat /etc/bind/db.local-::.arpa
;
; BIND reverse data file for local loopback interface
;
$TTL 604800
@ IN SOA localhost. root.localhost. (
8 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS localhost.
1 IN PTR localhost.
</pre>
<pre>
# cat /etc/bind/db.local-::1.arpa
;
; BIND reverse data file for local loopback interface
;
$TTL 604800
@ IN SOA localhost. root.localhost. (
8 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS localhost.
@ IN PTR localhost.
</pre>
<pre>
# cat /etc/bind/named.conf.default-zones.v6
zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" IN {
type master;
file "/etc/bind/db.local-::.arpa";
};
zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" IN {
type master;
file "/etc/bind/db.local-::1.arpa";
};
</pre>
Et on ajoute ca dans /etc/bind/named.conf:
<pre>
include "/etc/bind/named.conf.default-zones.v6";
</pre>
h3. Envoie d'un Router Advertissement avec scapy pour virer une route auto apprise (Attention à n'utiliser que si on sait ce qu'on fait ! )
Création de trame ipv6, ipv6 src est celle du router à spoffer
<pre>
a = IPv6()
a.src = "fe80::dcad:4dff:fe0b:8a5"
a.dst = "ff02::1"
</pre>
La trame sera un RA avec un lifetime de 0, comme indiquer dans la rfc2461:
"Lifetime of 0 indicates that the router is not a default router and SHOULD NOT appear on the default router list."
<pre>
b = ICMPv6ND_RA()
b.routerlifetime = 0
</pre>
Ensuite on fixe la adresse MAC Ã spoofer, celle du router original qui a envoyer le RA.
<pre>
c = ICMPv6NDOptSrcLLAddr()
c.lladdr = "00:50:56:24:3b:c0"
</pre>
Ensuite on construire le contenu du RA, avec le prefix à annoncer (toujours celui à spoofer)
Avec le validlifetime et preferredlifetime à l'infinie, comme indiquer dans la rfc2461:
"A value of all one bits (0xffffffff) represents infinity"
<pre>
d = ICMPv6NDOptMTU()
e = ICMPv6NDOptPrefixInfo()
e.prefixlen = 64
e.prefix = "2a01:6600:8081:4300::"
e.validlifetime = 0xffffffff
e.preferredlifetime = 0xffffffff
</pre>
On envoie le tout:
<pre>
send(a/b/c/d/e)
</pre>
h3. PMTU
Try 'tracepath6' it will show you which hop is not returning a packet
too big for that path if needed. Also one can use a series of "ping6 -s
<size> -M do" to check if packets pass or not (if the destination allows
pings of course).
h2. IETF IPv6 security
From: Fernando Gont <fernando@gont.com.ar>
To: NANOG <nanog@nanog.org>
Subject: IPv6 security: New IETF I-Ds, slideware and videos of recent presentations, trainings, etc...
Date: Mon, 28 May 2012 22:17:33 -0300
Folks,
* We've published a new IETF I-D entitled "DHCPv6-Shield: Protecting
Against Rogue DHCPv6 Servers", which is meant to provide RA-Guard-like
protection against rogue DHCPv6 servers. The I-D is available at:
<http://tools.ietf.org/id/draft-gont-opsec-dhcpv6-shield-00.txt>
Other IPv6 security I-Ds (such as,
draft-ietf-v6ops-ra-guard-implementation) have been revised. Please
check them out at:
<http://www.si6networks.com/publications/ietf.html>
* The slideware (and some videos!) of some of our recent presentations
about IPv6 security are now available online. You can find them at:
<http://www.si6networks.com/presentations/index.html>
* We have also scheduled IPv6 hacking trainings in Paris (France) and
Ghent (Belgium). You can find more details at:
<http://www.si6networks.com/index.html#conferences>
Our Twitter: @SI6Networks
ipv6hackers mailing-list:
<http://lists.si6networks.com/listinfo/ipv6hackers/>
Thanks!
Best regards,
--
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
h2. Protection de la vie privée
h3. Le problème
En IPv6 en mode "autoconfiguration" (SLAAC) les derniers 64 bits de
l'adresse sont dérivés de manière réversible de la MAC de votre
interface. Si celle-ci est par exemple 00:0c:29:0c:47:d5, elle est
modifiée comme sur ce schéma:
!/attachments/125/Modified-EUI-64.png! !/attachments/124/Modified-EUI-64.png!
Si vous êtes chez vous derrière une freebox vous allez apparaître avec
2a01:e34:...:02:0c:29:ff:fe:0c:47:d5 dans les logs des serveurs auxquels
vous vous connectez et si vous allez ensuite à Myrys vous serez en
2a01:6600:8080:505:...::02:0c:29:ff:fe:0c:47:d5.
Donc tous ces serveurs, en regardant la fin de l'adresse IPv6, peuvent
déduire que vous êtes un freenaute qui va à Myrys, avec les heures et
tout, vos visites chez vos amis, hotspot, hôtels, et ce même si vous
avez desactivé les cookies pour la partie web, si vous utilisez https,
etc... C'est un danger pour la vie privée non présent en IPv4.
h3. Solutions
h4. Au niveau du routeur
* On peut bloquer l'émission des RA pour ne pas avoir d'adresse SLAAC
sur les machines du réseau concerné (c'est ce qui est fait à Tetaneutral
il me semble...). Et mettre en place un serveur DHCPv6 qui affecte les
adresses IPv6 soit dynamiquement à partir d'un pool soit de manière
statique (mais sans correspondance connue avec une adresse MAC).
* Selon la puissance d'expression du pare-feu on peut bloquer les
adresses SLAAC. Elles ont les 2 octets 'ff fe' aux positions 11 et 12
dans l'adresse IPv6.
h4. Au niveau du client
* Activer l'extension privacy si ce n'est pas le cas par défaut,
(RFC3041 remplacé par RFC4941). Une manière de faire sous Linux
Debian est d'avoir un script /etc/network/if-pre-up.d/ipv6 contenant:
<pre>
#! /bin/sh
echo 2 > /proc/sys/net/ipv6/conf/$IFACE/use_tempaddr
</pre>
Ne pas oublier de rendre executable:
<pre>
chmod 755 /etc/network/if-pre-up.d/ipv6
</pre>
La commande 'ip -6 a' donnera alors après quelques heures une sortie telle que:
<pre>
6: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
inet6 2a01:6600:1122:3344:bc01:d69e:cb4d:f3f0/64 scope global temporary dynamic
valid_lft 73784sec preferred_lft 1784sec
inet6 2a01:6600:1122:3344:40d7:48ee:af65:47f1/64 scope global temporary deprecated dynamic
valid_lft 59792sec preferred_lft 0sec
inet6 2a01:6600:1122:3344:d59d:1447:62ab:1f29/64 scope global temporary deprecated dynamic
valid_lft 45515sec preferred_lft 0sec
inet6 2a01:6600:1122:3344:2xx:yyff:fezz:ttww/64 scope global dynamic
valid_lft 86313sec preferred_lft 14313sec
inet6 fe80::2xx:yyff:fezz:ttww/64 scope link
valid_lft forever preferred_lft forever
</pre>
où 00:xx:yy:zz:tt:ww est l'adresse MAC de l'interface (ici un bridge
qui prend l'adresse MAC de la première interface physique qui lui est
connectée). Les adresses 'deprecated' ne sont là que pour permettre
aux connexions démarrées durant leur durée de validité de
s'achever. Les nouvelles connexions utilisent la première adresse qui
a encore 1784 secondes de durée de vie restante.
* Modifier l'adresse MAC a chaque connexion
(OpenBSD propose 'ifconfig <if> lladdr random' pour cela :-)
* Bloquer avec le pare-feu local les paquets contenant l'adresse
SLAAC si possible.
Si les adresses IPv6 sont affectéees par un serveur DHCPv6 elles ne
sont normalement pas liées à l'adresse MAC.
h4. Liens
* http://www.rfc-editor.org/rfc/rfc4941.txt Le RFC sur les privacy extensions
* http://superuser.com/questions/243669/how-to-avoid-exposing-my-mac-address-when using-ipv6
* https://home.regit.org/2011/04/ipv6-privacy/ IPv6 privacy extensions on Linux
* http://www.queret.net/blog/2012/04/357/ IPv6: Ubuntu 12.04 active la RFC4941 (Privacy Extensions) par default
* http://support.menandmice.com/jforum/posts/list/219.page Enable Privacy extensions on Mac OS X 10.5 and 10.6
* http://tools.ietf.org/html/draft-ietf-6man-stable-privacy-addresses-01
h3. Mais...
Cela dit, il a été montré qu'il y a plein d'autres moyens pour les
sites web qui veulent traquer leurs utilisateurs de collecter des
informations discriminantes sur ceux-ci (type de navigateur,
extensions installées,...):
http://news.cnet.com/8301-1009_3-20005185-83.html
http://www.scatmania.org/2012/04/24/visitor-tracking-without-cookies/