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#head-22390d128ec029d35f54606bfa68964f2d67a717
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)
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.
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 ?
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...
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 :
root@rtrwrtfenint:~# 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 ?
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...
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 ?
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...
Eric Masson
Pascal Hambourg writes:
'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: <http://www.le-gnu.net> - C'est juste pour être sur... -+-
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: <http://www.le-gnu.net> - C'est juste pour être sur... -+-
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: <http://www.le-gnu.net> - C'est juste pour être sur... -+-
Pascal Hambourg
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.
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.
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.
Eric Masson
Pascal Hambourg writes:
'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 : <http://www.le-gnu.net> - Ce qui se conçoit bien ... -+-
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 : <http://www.le-gnu.net> - Ce qui se conçoit bien ... -+-
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 : <http://www.le-gnu.net> - Ce qui se conçoit bien ... -+-
Pascal Hambourg
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.
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.
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.
Eric Masson
Pascal Hambourg writes:
'Lut,
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.
Effectivement, c'est très clair et cela confirme mes observations.
Par contre, je viens de me rendre compte que WhiteRussian rc6 ne dispose pas d'une version de Netfilter qui gère les états en ip6, il va donc falloir que je fasse quelques tests avec Kamikaze sur le WGT634U.
Encore merci.
-- Pour restez connecté , téléchargez en même temps des mp3, vous verrez... -+- E in <http://www.le-gnu.net> La musisque adoucit les lamers -+-
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.
Effectivement, c'est très clair et cela confirme mes observations.
Par contre, je viens de me rendre compte que WhiteRussian rc6 ne dispose
pas d'une version de Netfilter qui gère les états en ip6, il va donc
falloir que je fasse quelques tests avec Kamikaze sur le WGT634U.
Encore merci.
--
Pour restez connecté , téléchargez en même temps des mp3, vous
verrez...
-+- E in <http://www.le-gnu.net> La musisque adoucit les lamers -+-
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.
Effectivement, c'est très clair et cela confirme mes observations.
Par contre, je viens de me rendre compte que WhiteRussian rc6 ne dispose pas d'une version de Netfilter qui gère les états en ip6, il va donc falloir que je fasse quelques tests avec Kamikaze sur le WGT634U.
Encore merci.
-- Pour restez connecté , téléchargez en même temps des mp3, vous verrez... -+- E in <http://www.le-gnu.net> La musisque adoucit les lamers -+-
Pascal Hambourg
Eric Masson a écrit :
Par contre, je viens de me rendre compte que WhiteRussian rc6 ne dispose pas d'une version de Netfilter qui gère les états en ip6, il va donc falloir que je fasse quelques tests avec Kamikaze sur le WGT634U.
Pour info le suivi de connexion IPv6 avec Linux nécessite au minimum un noyau 2.6.20 [1] et iptables 1.3.5, en activant les options de compilation qui vont bien.
[1] En fait le suivi de connexion IPv6 a été introduit dans le noyau 2.6.15, mais il lui manquait la prise en charge des protocoles "complexes" autres que FTP et il était incompatible avec la prise en charge du NAT IPv4.
Eric Masson a écrit :
Par contre, je viens de me rendre compte que WhiteRussian rc6 ne dispose
pas d'une version de Netfilter qui gère les états en ip6, il va donc
falloir que je fasse quelques tests avec Kamikaze sur le WGT634U.
Pour info le suivi de connexion IPv6 avec Linux nécessite au minimum un
noyau 2.6.20 [1] et iptables 1.3.5, en activant les options de
compilation qui vont bien.
[1] En fait le suivi de connexion IPv6 a été introduit dans le noyau
2.6.15, mais il lui manquait la prise en charge des protocoles
"complexes" autres que FTP et il était incompatible avec la prise en
charge du NAT IPv4.
Par contre, je viens de me rendre compte que WhiteRussian rc6 ne dispose pas d'une version de Netfilter qui gère les états en ip6, il va donc falloir que je fasse quelques tests avec Kamikaze sur le WGT634U.
Pour info le suivi de connexion IPv6 avec Linux nécessite au minimum un noyau 2.6.20 [1] et iptables 1.3.5, en activant les options de compilation qui vont bien.
[1] En fait le suivi de connexion IPv6 a été introduit dans le noyau 2.6.15, mais il lui manquait la prise en charge des protocoles "complexes" autres que FTP et il était incompatible avec la prise en charge du NAT IPv4.
Eric Masson
Pascal Hambourg writes:
'Re,
Pour info le suivi de connexion IPv6 avec Linux nécessite au minimum un noyau 2.6.20 [1] et iptables 1.3.5, en activant les options de compilation qui vont bien.
Sur Kamikaze 7.09/WGT634U, c'est un 2.6.22, cela devrait donc fonctionner, par contre ce qui me chiffonne, c'est de le mettre en production alors que la 8.08 est prévue pour dans pas lontemps...
En plus il faut que je fasse deux/trois modifs hard sur le WGT pour résoudre ses problèmes récurents de surchauffe et de portée faiblarde en wireless.
-- c'est qui tous ces gens bizarres ? c'est un cross post involontaire ou une invasion extraterrestre ? Y a pas qqun qui est censé faire cesse ce genre de c*nneries, genre un moderator ou un truc dans le genre .... -+- PM in: <http://www.le-gnu.net> - Bien configurer son moderator -+-
Pour info le suivi de connexion IPv6 avec Linux nécessite au minimum un
noyau 2.6.20 [1] et iptables 1.3.5, en activant les options de
compilation qui vont bien.
Sur Kamikaze 7.09/WGT634U, c'est un 2.6.22, cela devrait donc
fonctionner, par contre ce qui me chiffonne, c'est de le mettre en
production alors que la 8.08 est prévue pour dans pas lontemps...
En plus il faut que je fasse deux/trois modifs hard sur le WGT pour
résoudre ses problèmes récurents de surchauffe et de portée faiblarde en
wireless.
--
c'est qui tous ces gens bizarres ? c'est un cross post involontaire ou
une invasion extraterrestre ? Y a pas qqun qui est censé faire cesse ce
genre de c*nneries, genre un moderator ou un truc dans le genre ....
-+- PM in: <http://www.le-gnu.net> - Bien configurer son moderator -+-
Pour info le suivi de connexion IPv6 avec Linux nécessite au minimum un noyau 2.6.20 [1] et iptables 1.3.5, en activant les options de compilation qui vont bien.
Sur Kamikaze 7.09/WGT634U, c'est un 2.6.22, cela devrait donc fonctionner, par contre ce qui me chiffonne, c'est de le mettre en production alors que la 8.08 est prévue pour dans pas lontemps...
En plus il faut que je fasse deux/trois modifs hard sur le WGT pour résoudre ses problèmes récurents de surchauffe et de portée faiblarde en wireless.
-- c'est qui tous ces gens bizarres ? c'est un cross post involontaire ou une invasion extraterrestre ? Y a pas qqun qui est censé faire cesse ce genre de c*nneries, genre un moderator ou un truc dans le genre .... -+- PM in: <http://www.le-gnu.net> - Bien configurer son moderator -+-
