OpenBSD et IPv6 : adresse lien locale utilisee comme source de trames routables

Le
Benjamin Pineau
Bonjour,
j'essaie d'utiliser, avec OpenBSD, la connectivité IPv6 fournie
depuis avant-hier par Free, et je rencontre un problème bloquant.

Pour une même adresse de destination sur internet (destination à router,
pas sur le même segment que ma machine), le système choisi par moment
d'utiliser comme source des trames qu'il émet l'adresse lien local
(fe80:) de son interface externe (et donc les trames se perdent), et à
d'autres moments le système choisi d'utiliser l'adresse globale routable
de cette interface externe (2a01:5d8:5139:2a6c::2, et là ça marche bien).

Cela se produit « aléatoirement » sans que je ne change rien à la
configuration de la machine. Par exemple : je fais un
"ping6 www.kame.net", et tcpdump montre une adresse source en fe80
(lien local), et tout les paquets se perdent. J'arrête le ping6, je
le relance 5 minutes plus tard, et hop ça passe, les trames sont bien
émises par mon IP globale. 15 mn plus tard, de nouveau du fe80. Et ainsi
de suite. Enfin, l'idée est que c'est inconsistant, car en réalité ça
bloque la plupart du temps, et ça passe très rarement.

Le problème se produit indifféremment quelle que soit la façon dont
je configure la machine, à savoir :

* de façon dynamique :
sysctl net.inet6.ip6.accept_rtadv=1
rtsol rl1 # rl1 est mon interface externe

* à la main :
ifconfig rl1 inet6 2a01:5d8:5139:2a6c::2 prefixlen 64
route add -inet6 default 2a01:5d8:5139:2a6c::1

* de façon statique dans les fichiers de configuration :
echo inet6 alias 2a01:5d8:5139:2a6c::2 64 >> /etc/hostname.rl1
echo 2a01:5d8:5139:2a6c::1 >> /etc/mygate
reboot

Cette config semble correcte et fonctionnelle. Par exemple le ping6
vers mon next-hop marche toujours (normal, il est sur le même lien, il
peut donc répondre à une trame émise depuis une adresse lien local).

Autre problème, plus général, qui doit affecter beaucoup de BSDistes
utilisant l'IPv6 chez Free : la topologie choisie par Free pour
distribuer la connectivité IPv6 pause un probleme a ceux qui souhaitent
utiliser une passerelle entre leur LAN et le modem (freebox) : la freebox
n'accepte de router que les trames venant d'adresses qu'elle a découvert
par Neighbor Discovery, donc en théorie les adresses de machines branchées
sur le même lien/segment local, et pas des machines routées (ie. derrière
une passerelle BSD intermédiaire). La RFC 4389 (Neighbor Discovery Proxy)
décrit une solution standard à ce problème, mais je crois qu'on n'a pas
d'implémentation (et de toutes façons, itojun a écrit que « ND proxy is
simply evil, we should just prevent it, that is all. »).

Les linuxiens ont trouvé une astuce (http://ip6.fr/free-broute/)
consistant à faire un bridge spécial (qui ne bridge que le traffic IPv6,
et ne touche pas à l'IPv4 ni à l'arp) entre l'interface externe et
l'interface interne de la passerelle. Visiblement le brconfig(8) d'OpenBSD
ne permet pas de faire un bridge sélectif de ce type. J'ai pensé que,
peut-être, les règles "route-to" ou "dup-to" de pf.conf(5) pourraient
résoudre ce problème avec un BSD, mais je n'en suis pas sûr (et surtout
je ne peut rien tester vu mon autre problème). Avez vous des idées ?

Quelques compléments :
Mon firewall est tout ce qu'il y a de plus basique :

pass in quick inet6 proto icmp6
pass in quick inet6 proto tcp to port $tcp_services
pass in quick inet6 proto udp to port $udp_services
pass out quick inet6

Ma table de routage (netstat -rnfinet6, désolé ça fait plus de 80 cols) :

Internet6:
Destination Gateway Flags Refs Use Mtu Interface
::/104 ::1 UGRS 0 0 - lo0
::/96 ::1 UGRS 0 0 - lo0
default 2a01:5d8:5139:2a6c::1 UGS 2 24113 - rl1
::1 ::1 UH 14 0 33208 lo0
::127.0.0.0/104 ::1 UGRS 0 0 - lo0
::224.0.0.0/100 ::1 UGRS 0 0 - lo0
::255.0.0.0/104 ::1 UGRS 0 0 - lo0
::ffff:0.0.0.0/96 ::1 UGRS 0 0 - lo0
2002::/24 ::1 UGRS 0 0 - lo0
2002:7f00::/24 ::1 UGRS 0 0 - lo0
2002:e000::/20 ::1 UGRS 0 0 - lo0
2002:ff00::/24 ::1 UGRS 0 0 - lo0
2a01:5d8:5139:2a6c::/64 link#2 UC 1 0 - rl1
2a01:5d8:5139:2a6c::1 00:07:cb:09:0a:6e UHLc 1 921 - rl1
2a01:5d8:5139:2a6c::2 00:10:a7:1b:2f:89 UHL 0 0 - lo0
fe80::/10 ::1 UGRS 0 0 - lo0
fe80::%rl1/64 link#2 UC 1 0 - rl1
fe80::207:cbff:fe09:a6e%rl1 00:07:cb:09:0a:6e UHLc 0 654 - rl1
fe80::210:a7ff:fe1b:2f89%rl1 00:10:a7:1b:2f:89 UHL 1 0 - lo0
fe80::%ral0/64 link#3 UC 0 0 - ral0
fe80::213:d3ff:fe68:6eda%ral0 00:13:d3:68:6e:da UHL 0 0 - lo0
fe80::%re0/64 link#4 UC 0 0 - re0
fe80::208:a1ff:fe9c:677f%re0 00:08:a1:9c:67:7f UHL 0 0 - lo0
fe80::%lo0/64 fe80::1%lo0 U 0 0 - lo0
fe80::1%lo0 link#6 UHL 0 0 - lo0
fec0::/10 ::1 UGRS 0 0 - lo0
ff01::/16 ::1 UGRS 0 0 - lo0
ff01::%rl1/32 link#2 UC 0 0 - rl1
ff01::%ral0/32 link#3 UC 0 0 - ral0
ff01::%re0/32 link#4 UC 0 0 - re0
ff01::%lo0/32 ::1 UC 0 0 - lo0
ff02::/16 ::1 UGRS 0 0 - lo0
ff02::%rl1/32 link#2 UC 0 0 - rl1
ff02::%ral0/32 link#3 UC 0 0 - ral0
ff02::%re0/32 link#4 UC 0 0 - re0
ff02::%lo0/32 ::1 UC 0 0 - lo0

$ ifconfig rl1
rl1: flagsˆ43<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
lladdr 00:10:a7:1b:2f:89
groups: egress
media: Ethernet autoselect (100baseTX full-duplex)
status: active
inet 81.57.42.108 netmask 0xffffff00 broadcast 81.57.42.255
inet6 fe80::210:a7ff:fe1b:2f89%rl1 prefixlen 64 scopeid 0x2
inet6 2a01:5d8:5139:2a6c::2 prefixlen 64

Ping6 affiche ce que le kernel devrait faire mais ne fait pas
(utiliser l'adresse globale plutot que l'adresse locale comme source) :
$ ping6 www.kame.net
PING6(56@+8+8 bytes) 2a01:5d8:5139:2a6c::2 --> 2001:200:0:8002:203:47ff:fea5:3085

Exemple de sortie de "tcpdump -nvvs 1500 -i rl1 ip6 or proto ipv6 "
pendant un "ping6 www.kame.net" :
16:38:20.008553 fe80::210:a7ff:fe1b:2f89 > 2001:200:0:8002:203:47ff:fea5:3085: icmp6: echo request (len 16, hlim 64)
16:38:21.008695 fe80::210:a7ff:fe1b:2f89 > 2001:200:0:8002:203:47ff:fea5:3085: icmp6: echo request (len 16, hlim 64)
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Landry Breuil
Le #903837
Le 14 Dec 2007 18:15:05 GMT,

Bonjour,
j'essaie d'utiliser, avec OpenBSD, la connectivité IPv6 fournie
depuis avant-hier par Free, et je rencontre un problème bloquant.

Pour une même adresse de destination sur internet (destination à
router, pas sur le même segment que ma machine), le système choisi
par moment d'utiliser comme source des trames qu'il émet l'adresse
lien local (fe80:...) de son interface externe (et donc les trames se
perdent), et à d'autres moments le système choisi d'utiliser
l'adresse globale routable de cette interface externe
(2a01:5d8:5139:2a6c::2, et là ça marche bien).

Cela se produit « aléatoirement » sans que je ne change rien à la
configuration de la machine. Par exemple : je fais un
"ping6 www.kame.net", et tcpdump montre une adresse source en fe80
(lien local), et tout les paquets se perdent. J'arrête le ping6, je
le relance 5 minutes plus tard, et hop ça passe, les trames sont bien
émises par mon IP globale. 15 mn plus tard, de nouveau du fe80. Et
ainsi de suite. Enfin, l'idée est que c'est inconsistant, car en
réalité ça bloque la plupart du temps, et ça passe très raremen t.


J'aimerai bien faire la meme chose, et après avoir cherché sur internet
ca me parait difficilement faisable... le plus simple semble de
recourir au tunnel sixxs+rtadvd sur ta gateway et se passer de l'ipv6
free dans ce cas, ou passer la freebox en routeur et utiliser ta
gateway en pont filtrant. Le coup du bridge ipv6 a l'air un peu
goret... autre solution (en dernier recours), utiliser un frontal
linux/freebsd/netbsd et le 6to4 natif via l'interface stf.
Mais si tu trouves une solution élégante, je connais beaucoup de gens
qui seront preneurs :)

Enfin pour moi et le peu de tests que j'ai fait, si je lance rtsold -F
rl0 la connectivité ipv6 est constante et je peux pinguer www.kame.net
sans interruption. Et aussi, ne pas oublier que chez free le service est
encore "expérimental"..

Landry

Le problème se produit indifféremment quelle que soit la façon dont
je configure la machine, à savoir :

* de façon dynamique :
sysctl net.inet6.ip6.accept_rtadv=1
rtsol rl1 # rl1 est mon interface externe

* à la main :
ifconfig rl1 inet6 2a01:5d8:5139:2a6c::2 prefixlen 64
route add -inet6 default 2a01:5d8:5139:2a6c::1

* de façon statique dans les fichiers de configuration :
echo inet6 alias 2a01:5d8:5139:2a6c::2 64 >> /etc/hostname.rl1
echo 2a01:5d8:5139:2a6c::1 >> /etc/mygate
reboot

Cette config semble correcte et fonctionnelle. Par exemple le ping6
vers mon next-hop marche toujours (normal, il est sur le même lien,
il peut donc répondre à une trame émise depuis une adresse lien
local).

Autre problème, plus général, qui doit affecter beaucoup de BSDistes
utilisant l'IPv6 chez Free : la topologie choisie par Free pour
distribuer la connectivité IPv6 pause un probleme a ceux qui
souhaitent utiliser une passerelle entre leur LAN et le modem
(freebox) : la freebox n'accepte de router que les trames venant
d'adresses qu'elle a découvert par Neighbor Discovery, donc en
théorie les adresses de machines branchées sur le même lien/segment
local, et pas des machines routées (ie. derrière une passerelle BSD
intermédiaire). La RFC 4389 (Neighbor Discovery Proxy) décrit une
solution standard à ce problème, mais je crois qu'on n'a pas
d'implémentation (et de toutes façons, itojun a écrit que « ND pr oxy
is simply evil, we should just prevent it, that is all. »).

Les linuxiens ont trouvé une astuce (http://ip6.fr/free-broute/)
consistant à faire un bridge spécial (qui ne bridge que le traffic
IPv6, et ne touche pas à l'IPv4 ni à l'arp) entre l'interface externe
et l'interface interne de la passerelle. Visiblement le brconfig(8)
d'OpenBSD ne permet pas de faire un bridge sélectif de ce type. J'ai
pensé que, peut-être, les règles "route-to" ou "dup-to" de pf.conf( 5)
pourraient résoudre ce problème avec un BSD, mais je n'en suis pas
sûr (et surtout je ne peut rien tester vu mon autre problème). Avez
vous des idées ?

Quelques compléments :
Mon firewall est tout ce qu'il y a de plus basique :

pass in quick inet6 proto icmp6
pass in quick inet6 proto tcp to port $tcp_services
pass in quick inet6 proto udp to port $udp_services
pass out quick inet6

Ma table de routage (netstat -rnfinet6, désolé ça fait plus de 80
cols) :

Internet6:
Destination Gateway
Flags Refs Use Mtu
Interface ::/104 ::1
UGRS 0 0 -
lo0 ::/96 ::1
UGRS 0 0 - lo0
default 2a01:5d8:5139:2a6c::1
UGS 2 24113 -
rl1 ::1 ::1
UH 14 0 33208
lo0 ::127.0.0.0/104 ::1
UGRS 0 0 -
lo0 ::224.0.0.0/100 ::1
UGRS 0 0 -
lo0 ::255.0.0.0/104 ::1
UGRS 0 0 -
lo0 ::ffff:0.0.0.0/96 ::1
UGRS 0 0 - lo0
2002::/24 ::1
UGRS 0 0 - lo0
2002:7f00::/24 ::1
UGRS 0 0 - lo0
2002:e000::/20 ::1
UGRS 0 0 - lo0
2002:ff00::/24 ::1
UGRS 0 0 - lo0
2a01:5d8:5139:2a6c::/64 link#2
UC 1 0 - rl1
2a01:5d8:5139:2a6c::1 00:07:cb:09:0a:6e
UHLc 1 921 - rl1
2a01:5d8:5139:2a6c::2 00:10:a7:1b:2f:89
UHL 0 0 - lo0
fe80::/10 ::1
UGRS 0 0 - lo0
fe80::%rl1/64 link#2
UC 1 0 - rl1
fe80::207:cbff:fe09:a6e%rl1 00:07:cb:09:0a:6e
UHLc 0 654 - rl1
fe80::210:a7ff:fe1b:2f89%rl1 00:10:a7:1b:2f:89
UHL 1 0 - lo0
fe80::%ral0/64 link#3
UC 0 0 - ral0
fe80::213:d3ff:fe68:6eda%ral0 00:13:d3:68:6e:da
UHL 0 0 - lo0
fe80::%re0/64 link#4
UC 0 0 - re0
fe80::208:a1ff:fe9c:677f%re0 00:08:a1:9c:67:7f
UHL 0 0 - lo0
fe80::%lo0/64 fe80::1%lo0
U 0 0 - lo0
fe80::1%lo0 link#6
UHL 0 0 - lo0
fec0::/10 ::1
UGRS 0 0 - lo0
ff01::/16 ::1
UGRS 0 0 - lo0
ff01::%rl1/32 link#2
UC 0 0 - rl1
ff01::%ral0/32 link#3
UC 0 0 - ral0
ff01::%re0/32 link#4
UC 0 0 - re0
ff01::%lo0/32 ::1
UC 0 0 - lo0
ff02::/16 ::1
UGRS 0 0 - lo0
ff02::%rl1/32 link#2
UC 0 0 - rl1
ff02::%ral0/32 link#3
UC 0 0 - ral0
ff02::%re0/32 link#4
UC 0 0 - re0
ff02::%lo0/32 ::1
UC 0 0 - lo0

$ ifconfig
rl1 rl1: flagsˆ43<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
lladdr 00:10:a7:1b:2f:89
groups: egress
media: Ethernet autoselect (100baseTX full-duplex)
status: active
inet 81.57.42.108 netmask 0xffffff00 broadcast 81.57.42.255
inet6 fe80::210:a7ff:fe1b:2f89%rl1 prefixlen 64 scopeid 0x2
inet6 2a01:5d8:5139:2a6c::2 prefixlen 64

Ping6 affiche ce que le kernel devrait faire mais ne fait pas
(utiliser l'adresse globale plutot que l'adresse locale comme
source) : $ ping6 www.kame.net
PING6(56@+8+8 bytes) 2a01:5d8:5139:2a6c::2 -->
2001:200:0:8002:203:47ff:fea5:3085

Exemple de sortie de "tcpdump -nvvs 1500 -i rl1 ip6 or proto ipv6 "
pendant un "ping6 www.kame.net" :
16:38:20.008553 fe80::210:a7ff:fe1b:2f89 >
2001:200:0:8002:203:47ff:fea5:3085: icmp6: echo request (len 16, hlim
64) 16:38:21.008695 fe80::210:a7ff:fe1b:2f89 >
2001:200:0:8002:203:47ff:fea5:3085: icmp6: echo request (len 16, hlim
64)



Benjamin Pineau
Le #903836
Le Mon, 17 Dec 2007 09:54:14 +0100,
Landry Breuil

J'aimerai bien faire la meme chose, et après avoir cherché sur internet
ca me parait difficilement faisable... le plus simple semble de
recourir au tunnel sixxs+rtadvd sur ta gateway et se passer de l'ipv6
free dans ce cas, ou passer la freebox en routeur et utiliser ta
gateway en pont filtrant. Le coup du bridge ipv6 a l'air un peu
goret... autre solution (en dernier recours), utiliser un frontal
linux/freebsd/netbsd et le 6to4 natif via l'interface stf.
Mais si tu trouves une solution élégante, je connais beaucoup de gens
qui seront preneurs :)


Pour l'utilisation de dup-to et route-to c'est compromis : on ne
peut pas spécifier l'"address family" avec ce type de règles.
Par ex :
pass in on egress dup-to re0 all # syntaxe ok
pass in on egress inet6 dup-to re0 all # erreur de syntaxe

Une autre possibilité à explorer, la redirection du traffic de la
neighbor discovery (ICMPv6 types 133, 134, 135, 136 et 137, ou en
termes "icmp6-type" pf.conf(5), neighbrsol, neighbradv, routersol et
routeradv) avec des règles "rdr" pf(4), ou sa duplication avec
"dup-to". Mais là encore pfctl(8) ne semble pas si souple :
# Ceci est ok
rdr pass on egress inet6 proto icmp6 all -> 2a01:5d8:5139:2a6c::4
# Ceci produit une erreur de syntaxe
rdr pass on egress inet6 proto icmp6 all icmp6-type routeradv ->
2a01:5d8:5139:2a6c::4

Aussi, la page de man ndp(4) indique un mode proxy, mais apparement
il faudrait ajouter les entrées à la main, ce qui n'est pas vraiment
pratique.

Enfin pour moi et le peu de tests que j'ai fait, si je lance rtsold -F
rl0 la connectivité ipv6 est constante et je peux pinguer www.kame.net
sans interruption. Et aussi, ne pas oublier que chez free le service est
encore "expérimental"..


Finallement c'est tombé en marche chez moi aussi, assez étrangement,
il suffit que j'assigne une seconde adresse unicast global à l'interface
externe et hop, ça roule. Pas eu le temps de chercher plus avant.

Raphael Mazelier
Le #903663

Aussi, la page de man ndp(4) indique un mode proxy, mais apparement
il faudrait ajouter les entrées à la main, ce qui n'est pas vraiment
pratique.

Finallement c'est tombé en marche chez moi aussi, assez étrangement,
il suffit que j'assigne une seconde adresse unicast global à l'interface
externe et hop, ça roule. Pas eu le temps de chercher plus avant.



Salut,

Moi aussi j'ai le même problème, a savoir que mon interface externe
utilise systématiquement avec comme source son adresse lien local.
Cela ne change rien que je configure statiquement ou avec rtsol ?
Peux tu poster ta configuration qui est tombé en marche, car pour le
moment le seul moyen que j'ai trouvé c'est de faire un ifconfig delete
de l'@ipv6 lien local. C'est assez crade.
Au passage je déconseille de jouer avec ndp, je viens de vautrer ma
passerelle à distance :(

Par ailleurs toujours pas de solutions pour router l'ipv6 avec le /64 de
free ?

--
raf

Benjamin Pineau
Le #903662
Le Tue, 18 Dec 2007 15:36:03 +0100,
Raphael Mazelier

Moi aussi j'ai le même problème, a savoir que mon interface externe
utilise systématiquement avec comme source son adresse lien local.
Cela ne change rien que je configure statiquement ou avec rtsol ?
Peux tu poster ta configuration qui est tombé en marche, car pour le
moment le seul moyen que j'ai trouvé c'est de faire un ifconfig delete
de l'@ipv6 lien local. C'est assez crade.


Je configure d'abord le réseau IPv6 de façon classique, ce qui expose
provisoirement le probleme dont on parle :
ifconfig rl1 inet6 2a01:5d8:5139:2a6c::2 prefixlen 64
route add -inet6 default 2a01:5d8:5139:2a6c::1

Ensuite j'ajoute une seconde adresse IPv6 globale unicast sur la même
interface (externe) :
ifconfig rl1 inet6 2a01:5d8:5139:2a6c::3

Et hop, maintenant ça passe ! (l'adresse source utilisé est celle
du dernier alias, le :3, va comprendre).

Par ailleurs toujours pas de solutions pour router l'ipv6 avec le /64 de
free ?


Rien trouvé, en ce qui me concerne.

Michel Parlebas
Le #903661

Par ailleurs toujours pas de solutions pour router l'ipv6 avec le /64 de
free ?


Rien trouvé, en ce qui me concerne.



Si j'ai bien tout compris, Free propose un 6to4 "déguisé" de manière à
ne pas présenter une adresse en 2002:... mais avec lequel on ne peut
rien router...

...alors qu'avec un 6to4 "classique", on a - bien sûr - une adresse en
2002: mais on peut router ce qu'on veut, on dispose d'un /48 et on peut
disposer d'une reverse...

Est-ce bien résumé ? :-)

--
MP


Raphael Mazelier
Le #903660

Je configure d'abord le réseau IPv6 de façon classique, ce qui expose
provisoirement le probleme dont on parle :
ifconfig rl1 inet6 2a01:5d8:5139:2a6c::2 prefixlen 64
route add -inet6 default 2a01:5d8:5139:2a6c::1

Ensuite j'ajoute une seconde adresse IPv6 globale unicast sur la même
interface (externe) :
ifconfig rl1 inet6 2a01:5d8:5139:2a6c::3

En fait j'avais testé de ta maniére aussi (sans auto-configuration) et

cela ne marche pas non plus dans mon cas. En fait dans mon cas l'adresse
source utilisée est aléatoire !? Donc si je ping6 www.kame.net une fois
ca passe une fois ca passe pas :) Le plus drole c'est qu'en rajoutant
plus d'alias, par exemple :

inet6 fe80::20a:5eff:fe3d:419d%xl0 prefixlen 64 scopeid 0x2
inet6 2a01:5d8:abcd:832c::100 prefixlen 64
inet6 2a01:5d8:abcd:832c::101 prefixlen 64

J'ai en moyenne 2/3 des ping qui arrivent. Je n'ai rien trouvé dans la
documentation kame, ndp, bsd sur ipv6 de solution.


Et hop, maintenant ça passe ! (l'adresse source utilisé est celle
du dernier alias, le :3, va comprendre).



Et bien au moins il s'agirait d'un comportement compréhensible et
déterministe. Je pense que je vais faire un bug-report.

--
Raphael Mazelier

Pascal Hambourg
Le #903659
Salut,


Si j'ai bien tout compris, Free propose un 6to4 "déguisé" de manière à
ne pas présenter une adresse en 2002:...


C'est surtout pour pouvoir proposer de l'IPv6 natif avant même que tout
le réseau de collecte ADSL, DSLAM, routeurs et compagnie, soit
compatible IPv6. Le "6to4rd" est de la cuisine interne qui reste
transparente pour les abonnés et le reste du monde IPv6 (à part le path
MTU à 1480 à cause de l'encapsulation dans IPv4).

mais avec lequel on ne peut rien router...


C'est le gros défaut, tout le bloc est routé directement sur l'interface
LAN de la Freebox.

...alors qu'avec un 6to4 "classique", on a - bien sûr - une adresse en
2002: mais on peut router ce qu'on veut, on dispose d'un /48 et on peut
disposer d'une reverse...


Oui, mais avec des chemins de retour aléatoires selon les destinations.

Publicité
Poster une réponse
Anonyme