Accès Premium
GNT sans publicité, site mobile, fonctionnalitées exclusives...
Rejoignez-nous !
Forums Matériel Réseaux et Internet IP

OpenWRT & 6to4

Le
Eric Masson
'Lut,

Je suis entrain de jouer avec un Linksys sous OpenWRT pour tenter de le
raccorder au vaste monde ipv6.

Je tente donc d'utiliser 6to4 mais je rencontre des difficultés.
État des lieux :
- kmod-ipv6 chargé (ça marche mieux avec parait-il)
- Utilisation d'un script présent sur le Wiki d'OpenWRT :
http://wiki.openwrt.org/IPv6_howto#...4f2d67a717

Après exécution du script, l'état des interfaces est le suivant :
(les interfaces qui ne me semblent pas liées au problème ont été
retirées).
root@rtrwrtfenint:~# ifconfig -a
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

sit0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
NOARP MTU:1480 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

tun6to4 Link encap:UNSPEC HWaddr D9-80-C8-30-00-00-00-00-00-00-00-00-00-00-00-00
inet6 addr: 2002:d980:c830::1/16 Scope:Global
inet6 addr: ::217.128.200.48/128 Scope:Compat
UP RUNNING NOARP MTU:1480 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:14 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:1736 (1.6 KiB)

vlan1 Link encap:Ethernet HWaddr 00:0F:66:C8:B9:66
inet addr:217.128.200.48 Bcast:223.255.255.255 Mask:224.0.0.0
inet6 addr: fe80::20f:66ff:fec8:b966/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1480 Metric:1
RX packets:4003 errors:0 dropped:0 overruns:0 frame:0
TX packets:2856 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:4171792 (3.9 MiB) TX bytes:341613 (333.6 KiB)

La table de routage ipv6 est la suivante :
root@rtrwrtfenint:~# ip -6 route show
::/96 via :: dev tun6to4 metric 256 mtu 1480 advmss 1420
2002:d980:c830:1234::/64 dev br0 metric 256 mtu 1500 advmss 1440
2002::/16 dev tun6to4 metric 256 mtu 1480 advmss 1420
2000::/3 via ::192.88.99.1 dev tun6to4 metric 1 mtu 1480 advmss 1420
fe80::/64 dev eth0 metric 256 mtu 1500 advmss 1420
fe80::/64 dev vlan0 metric 256 mtu 1500 advmss 1420
fe80::/64 dev eth1 metric 256 mtu 1500 advmss 1420
fe80::/64 dev br0 metric 256 mtu 1500 advmss 1420
fe80::/64 dev vlan1 metric 256 mtu 1480 advmss 1420
fe80::/64 dev ipsec0 metric 256 mtu 16260 advmss 16200
fe80::/64 dev tun6to4 metric 256 mtu 1480 advmss 1420
ff00::/8 dev eth0 metric 256 mtu 1500 advmss 1420
ff00::/8 dev vlan0 metric 256 mtu 1500 advmss 1420
ff00::/8 dev eth1 metric 256 mtu 1500 advmss 1420
ff00::/8 dev br0 metric 256 mtu 1500 advmss 1420
ff00::/8 dev vlan1 metric 256 mtu 1480 advmss 1420
ff00::/8 dev ipsec0 metric 256 mtu 16260 advmss 16200
ff00::/8 dev tun6to4 metric 256 mtu 1480 advmss 1420
unreachable default dev lo proto none metric -1 error -128 advmss 1420

Un ping6 à destination de www.kame.net (*) génère bien du trafic sortant
à destination de l'adresse anycast 6to4 sur l'interface wan du WRT :
root@rtrwrtfenint:~# tcpdump -n -i vlan1 host 192.88.99.1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vlan1, link-type EN10MB (Ethernet), capture size 96 bytes
17:18:55.863214 arp who-has 192.88.99.1 tell 217.128.200.48
17:18:55.863556 arp reply 192.88.99.1 is-at 00:16:b6:fb:ad:e6
17:18:55.863688 IP 217.128.200.48 > 192.88.99.1: IP6 2002:d980:c830::1 > 2001:200:0:8002:203:47ff:fea5:3085: ICMP6, echo request, seq 0, length 64
17:18:56.867508 IP 217.128.200.48 > 192.88.99.1: IP6 2002:d980:c830::1 > 2001:200:0:8002:203:47ff:fea5:3085: ICMP6, echo request, seq 256, length 64
17:18:57.867542 IP 217.128.200.48 > 192.88.99.1: IP6 2002:d980:c830::1 > 2001:200:0:8002:203:47ff:fea5:3085: ICMP6, echo request, seq 512, length 64
17:18:58.867505 IP 217.128.200.48 > 192.88.99.1: IP6 2002:d980:c830::1 > 2001:200:0:8002:203:47ff:fea5:3085: ICMP6, echo request, seq 768, length 64
17:18:59.867505 IP 217.128.200.48 > 192.88.99.1: IP6 2002:d980:c830::1 > 2001:200:0:8002:203:47ff:fea5:3085: ICMP6, echo request, seq 1024, length 64
17:19:00.867506 IP 217.128.200.48 > 192.88.99.1: IP6 2002:d980:c830::1 > 2001:200:0:8002:203:47ff:fea5:3085: ICMP6, echo request, seq 1280, length 64
17:19:01.867528 IP 217.128.200.48 > 192.88.99.1: IP6 2002:d980:c830::1 > 2001:200:0:8002:203:47ff:fea5:3085: ICMP6, echo request, seq 1536, length 64
17:19:02.867501 IP 217.128.200.48 > 192.88.99.1: IP6 2002:d980:c830::1 > 2001:200:0:8002:203:47ff:fea5:3085: ICMP6, echo request, seq 1792, length 64

Bref, je sèche. Quelqu'un aurait-il une idée géniale ?

* : Moi aussi je veux voir la tortue qui danse :)

--
RHF> Là Francis tu va trop loin.
C'est ce qu'elles disent toutes.
-+- FC in <http://www.le-gnu.net> : Bourre z'y l'mou.
Lire les 8 réponses

Questions / Réponses high-tech
Poser une question
Vidéos High-Tech et Jeu Vidéo
Plus de vidéos
Téléchargements
Plus de téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Pascal Hambourg
Le #16642571
Salut,

Eric Masson a écrit :

tun6to4 Link encap:UNSPEC HWaddr D9-80-C8-30-00-00-00-00-00-00-00-00-00-00-00-00
inet6 addr: 2002:d980:c830::1/16 Scope:Global
inet6 addr: ::217.128.200.48/128 Scope:Compat



RAS.

vlan1 Link encap:Ethernet HWaddr 00:0F:66:C8:B9:66
inet addr:217.128.200.48 Bcast:223.255.255.255 Mask:224.0.0.0



C'est normal, ce masque ?

La table de routage ipv6 est la suivante :



RAS.

Tu as bien autorisé les paquets IPv4 proto 41 en INPUT sur vlan1 dans
les règles iptables ?

Un ping6 à destination de www.kame.net (*) génère bien du trafic sortant
à destination de l'adresse anycast 6to4 sur l'interface wan du WRT :
:~# tcpdump -n -i vlan1 host 192.88.99.1



Les relais 6to4 n'émettent pas forcément le trafic encapsulé avec
l'adresse anycast 192.88.99.1 comme adresse source. Au lieu de filtrer
sur l'adresse, filtre plutôt sur le protocole IP 41 (ipv6).

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vlan1, link-type EN10MB (Ethernet), capture size 96 bytes
17:18:55.863214 arp who-has 192.88.99.1 tell 217.128.200.48
17:18:55.863556 arp reply 192.88.99.1 is-at 00:16:b6:fb:ad:e6



Hein ? C'est quoi ça ? Ah, je crois que je comprends, tu as un modem
ADSL en demi-pont qui fait du proxy ARP ?

17:18:55.863688 IP 217.128.200.48 > 192.88.99.1: IP6 2002:d980:c830::1 > 2001:200:0:8002:203:47ff:fea5:3085: ICMP6, echo request, seq 0, length 64
17:18:56.867508 IP 217.128.200.48 > 192.88.99.1: IP6 2002:d980:c830::1 > 2001:200:0:8002:203:47ff:fea5:3085: ICMP6, echo request, seq 256, length 64


[...]
* : Moi aussi je veux voir la tortue qui danse :)



J'ai une mauvaise nouvelle : je crains que www.kame.net ne réponde pas
aux adresses 6to4. J'ai une double connectivité IPv6 native+6to4, et ce
serveur ne répond pas à mes requêtes quand j'utilise une adresse source
6to4.

Essaie plutôt avec des serveurs qui répondent aux adresses 6to4 (et au
ping) comme ftp.nerim.net, www.free.fr, www.ipv6.org...
Répondre en citant
Eric Masson
Le #16645331
Pascal Hambourg
'Lut Pascal,

J'sais pas pourquoi, mais je me doutais que tu serais sur le coup ;)

vlan1 Link encap:Ethernet HWaddr 00:0F:66:C8:B9:66
inet addr:217.128.200.48 Bcast:223.255.255.255 Mask:224.0.0.0



C'est normal, ce masque ?



À priori oui, vu que ce sont les paramètres fournis par Orange
(abonnement pro)

Tu as bien autorisé les paquets IPv4 proto 41 en INPUT sur vlan1 dans
les règles iptables ?



Je l'ai rajouté à postériori et cela a débloqué la situation.
Par contre, je ne capte pas vraiment le pourquoi, 41 est le type du
trafic ipv6, pas d'une encapsulation v6 dans v4.

Les relais 6to4 n'émettent pas forcément le trafic encapsulé avec
l'adresse anycast 192.88.99.1 comme adresse source. Au lieu de filtrer
sur l'adresse, filtre plutôt sur le protocole IP 41 (ipv6).



Effectivement, j'avais bien mes réponses dès le début. Par contre la
question du filtrage sur le protocole 41 reste en suspens.

Hein ? C'est quoi ça ? Ah, je crois que je comprends, tu as un modem
ADSL en demi-pont qui fait du proxy ARP ?



Exact, cela m'a permis de passer de Free à Orange sans devoir
reconfigurer le WRT en PPPoE.

J'ai une mauvaise nouvelle : je crains que www.kame.net ne réponde pas
aux adresses 6to4. J'ai une double connectivité IPv6 native+6to4, et ce
serveur ne répond pas à mes requêtes quand j'utilise une adresse source
6to4.



Effectivement, cela semble être le cas, je vais peut-être me fendre d'un
mail à ce sujet au webmaster du projet.

Merci pour ton aide.

--
N> La radio pourrait etre incluse dans ce forum.
B> Dans un groupe s'appelant TV ? fr.rec.radio parle de quoi ?
N> j'ai dis une connerie ?
-+- in:
Répondre en citant
Pascal Hambourg
Le #16645921
Eric Masson a écrit :

J'sais pas pourquoi, mais je me doutais que tu serais sur le coup ;)



Eh, c'est ma modeste contribution à la diffusion d'IPv6.

À priori oui, vu que ce sont les paramètres fournis par Orange
(abonnement pro)



A propos d'Orange, ils en sont où avec l'IPv6 depuis la fin de leur
expérimentation ?

Tu as bien autorisé les paquets IPv4 proto 41 en INPUT sur vlan1 dans
les règles iptables ?



Je l'ai rajouté à postériori et cela a débloqué la situation.
Par contre, je ne capte pas vraiment le pourquoi, 41 est le type du
trafic ipv6, pas d'une encapsulation v6 dans v4.



Qu'entends-tu par "type du trafic IPv6" ? 41 est bien le numéro de
protocole IPv4 qui encapsule le trafic IPv6 en 6to4.
Répondre en citant
Eric Masson
Le #16648621
Pascal Hambourg
'Re,

Eh, c'est ma modeste contribution à la diffusion d'IPv6.



Sois pas si modeste.

A propos d'Orange, ils en sont où avec l'IPv6 depuis la fin de leur
expérimentation ?



Bonne question, je n'ai aucune information sur le sujet.

Qu'entends-tu par "type du trafic IPv6" ? 41 est bien le numéro de
protocole IPv4 qui encapsule le trafic IPv6 en 6to4.



Ok, confusion de ma part, je vais reprendre quelques traces en natif et
en 6to4, puis les analyser avec Wireshark pour être sûr d'avoir bien
compris.

Encore merci de ton aide.

--
RXN0LWNlIHF1J29uIHV0aWxpc2UgdW4gcHJvZ3JhbW1lIGRlIGxvZpwbv
bm5lY3RlciBhIEN5YmVyY2FibGUsDQpwb3VyIGVudHJlciBsZSBub20ZG9
bGUgcGFzc3dvcmQgPw0KU2kgb3VpLCBxdWVsIHByb2dyYW1tZSBlc3Qta
-+-UK in :
Répondre en citant
Pascal Hambourg
Le #16650601
Eric Masson a écrit :

Ok, confusion de ma part, je vais reprendre quelques traces en natif et
en 6to4, puis les analyser avec Wireshark pour être sûr d'avoir bien
compris.



Tu verras le trafic encapsulé dans IPv4 sur l'interface vlan1, et le
trafic IPv6 natif sur l'interface 6to4tun.

Il y a quelques subtilités pour la capture de trafic IPv6 avec tcpdump,
je suppose que c'est la même chose avec wireshark. En particulier il ne
faut pas confondre 'ipv6' qui représente le protocole IP 41
d'encapsulation IPv6 dans IPv4 (6in4) utilisé par 6to4, et 'ip6' qui
représente l'ethertype 0x86dd d'une trame ethernet (ou équivalent)
transportant un paquet IPv6 natif. Le point délicat est que certains
types de liaison, notamment point à point (PPP, tunnel) n'ont pas
d'ethertype pour identifier le protocole et donc on ne peut pas utiliser
le filtre 'ip6'. Ce n'est pas gênant avec une interface 6to4 qui ne
transporte que de l'IPv6, mais cela peut l'être avec une interface PPP
ou tunnel en mode routé (tun) qui peut transporter à la fois de l'IPv4
et de l'IPv6. Dans ce cas, un moyen de différencier IPv4 et IPv6 est de
filtrer sur le champ de version de l'en-tête IP.
Répondre en citant
Publicité
Suivre les réponses
Poster une réponse
Anonyme