Tunnels gre0, sit0, tunl0

TiChou

04/11/2004 à 13:59

Dans le message <news:cmbtrb$2du8$,
** tapota sur f.c.o.l.configuration :

Salut,

Bonjour,

Je découvre les différents types de tunnels avec Linux, IP/GRE, IPv6/IP,
IP/IP avec un noyau 2.4.18. Au chargement des modules du noyau
correspondants, une interface est créée automatiquement :
- ip_gre.o -> gre0
- ipv6.o -> sit0
- ipip.o -> tunl0

[...] je ne comprends pas comment utiliser les tunnels gre0, sit0 ou tunl0
créés automatiquement.

[...]

Alors, il y a un truc qui m'échappe ou bien ces interfaces seraient
inutilisables [...] ?

Effectivement, ces interfaces virtuelles ne peuvent pas être affectées au
montage de tunnels classiques.
C'est de toute manière des interfaces qu'on recommande de ne plus utiliser.

Par exemple, on utilisait auparavant l'interface IPv6 sit0 pour faire de
façon simple du 6to4. On configurait les adresses IPv6 sur cette interface
et on créait une simple route vers un routeur sachant faire du 6to4.

$ ip addr add 2002:52e1:6c2b::/64 dev sit0
$ ip ro add 2000::/3 via ::192.88.99.1

Mais on ne créait pas réellement un tunnel.

Aujourd'hui, pour faire du 6to4 (on en fait encore ? :p) on crée un vrai
tunnel dédié :

$ ip tunnel add 6to4 mode sit remote 192.88.99.1 local any
$ ip link set 6to4 up
$ ip link set mtu 1280 dev 6to4
$ ip ro add 2000::/3 dev 6to4
$ ip addr add 2002:52e1:6c2b::/64 dev 6to4

On se servait aussi de ces interfaces comme « tremplin » pour créer de
nouvelles interfaces virtuelles.
Par exemple, on passait par l'interface sit0 pour créer des nouvelles
interfaces sitX avec la commande ifconfig pour monter des nouveaux tunnels.

$ ifconfig sit0 tunnel ::213.197.27.252
$ ifconfig sit1 up
$ ifconfig sit0 tunnel ::213.204.193.2
$ ifconfig sit2 up

Ces deux commandes permettaient de créer successivement les interfaces et
tunnels sit1 et sit2.

Aujourd'hui on préfère utiliser la syntaxe suivante :

$ ip tunnel add pwet mode sit remote 213.197.27.252 ttl 64
$ ip link set pwet up
$ ip tunnel add gniii mode sit remote 213.204.193.2 ttl 64
$ ip link set gniii up

--
TiChou

Dans le message <news:cmbtrb$2du8$1@biggoron.nerim.net>,
*Pascal@plouf* tapota sur f.c.o.l.configuration :

Salut,

Bonjour,

Je découvre les différents types de tunnels avec Linux, IP/GRE, IPv6/IP,
IP/IP avec un noyau 2.4.18. Au chargement des modules du noyau
correspondants, une interface est créée automatiquement :
- ip_gre.o -> gre0
- ipv6.o -> sit0
- ipip.o -> tunl0

[...] je ne comprends pas comment utiliser les tunnels gre0, sit0 ou tunl0
créés automatiquement.

[...]

Alors, il y a un truc qui m'échappe ou bien ces interfaces seraient
inutilisables [...] ?

Effectivement, ces interfaces virtuelles ne peuvent pas être affectées au
montage de tunnels classiques.
C'est de toute manière des interfaces qu'on recommande de ne plus utiliser.

Par exemple, on utilisait auparavant l'interface IPv6 sit0 pour faire de
façon simple du 6to4. On configurait les adresses IPv6 sur cette interface
et on créait une simple route vers un routeur sachant faire du 6to4.

$ ip addr add 2002:52e1:6c2b::/64 dev sit0
$ ip ro add 2000::/3 via ::192.88.99.1

Mais on ne créait pas réellement un tunnel.

Aujourd'hui, pour faire du 6to4 (on en fait encore ? :p) on crée un vrai
tunnel dédié :

$ ip tunnel add 6to4 mode sit remote 192.88.99.1 local any
$ ip link set 6to4 up
$ ip link set mtu 1280 dev 6to4
$ ip ro add 2000::/3 dev 6to4
$ ip addr add 2002:52e1:6c2b::/64 dev 6to4

On se servait aussi de ces interfaces comme « tremplin » pour créer de
nouvelles interfaces virtuelles.
Par exemple, on passait par l'interface sit0 pour créer des nouvelles
interfaces sitX avec la commande ifconfig pour monter des nouveaux tunnels.

$ ifconfig sit0 tunnel ::213.197.27.252
$ ifconfig sit1 up
$ ifconfig sit0 tunnel ::213.204.193.2
$ ifconfig sit2 up

Ces deux commandes permettaient de créer successivement les interfaces et
tunnels sit1 et sit2.

Aujourd'hui on préfère utiliser la syntaxe suivante :

$ ip tunnel add pwet mode sit remote 213.197.27.252 ttl 64
$ ip link set pwet up
$ ip tunnel add gniii mode sit remote 213.204.193.2 ttl 64
$ ip link set gniii up

--
TiChou

Vous avez filtré cet utilisateur ! Consultez son message

Nicolas George

04/11/2004 à 14:23

"TiChou" wrote in message :

Aujourd'hui, pour faire du 6to4 (on en fait encore ? :p)

Pourquoi n'en ferait-on plus ? J'en ai sur les machines que je contrôle qui
n'ont pas d'IPv6 natif, et des amis en utilisent aussi. J'ai même un tunnel
6to4 sans IP sur ma machine principale, juste pour pouvoir faire une route
directe dans les cas que j'utilise le plus.

TiChou

04/11/2004 à 16:30

Dans le message <news:cmdagm$30ge$,
*Nicolas George* tapota sur f.c.o.l.configuration :

Aujourd'hui, pour faire du 6to4 (on en fait encore ? :p)

Pourquoi n'en ferait-on plus ?

Parce que d'une part j'observe aujourd'hui et depuis longtemps qu'on se
fournit en IPv6 soit en natif quand le FAI le propose ou soit en passant par
un fournisseur de tunnel (tunnel broker). Et parce que d'autre part la
connectivité IPv6 chez un tunnel broker ou en natif est généralement bien
meilleure en terme de bande passante, de latence et de stabilité que via un
relais 6to4.
De plus les relais 6to4 publiques ouverts sont de plus en plus rares.

J'en ai sur les machines que je contrôle qui n'ont pas d'IPv6 natif, et
des
amis en utilisent aussi.

Et bien tu me surprends, parce que je m'intéresse à l'IPv6 depuis plusieurs
années avec plusieurs amis, nous avons tous nos réseaux en IPv6, mais je
n'en connais aucun qui fait du 6to4.
Et pour ma part, j'utilise le 6to4 que de façon temporelle, par exemple pour
tester vite fait la pile IPv6 d'une machine fraîchement installée.

J'ai même un tunnel 6to4 sans IP sur ma machine principale, juste pour
pouvoir faire une route directe dans les cas que j'utilise le plus.

C'est-à-dire ? Peux-tu en dire plus ?

--
TiChou

Nicolas George

04/11/2004 à 20:50

"TiChou" wrote in message :

Et parce que d'autre part la
connectivité IPv6 chez un tunnel broker ou en natif est généralement bien
meilleure en terme de bande passante, de latence et de stabilité que via un
relais 6to4.

Un tunnel broker, ça donne une connexion point à point, c'est bien ça ?
(si ce n'est pas ça, merci d'ignorer le paragraphe qui suit, et de me
corriger)

Dans ce cas, la connexion est certainement meilleure entre le réseau à cette
extrémité et le monde IPv6. En revanche, de 6to4 à 6to4, ou de 6to4 à un
IPv6 avec un routage direct comme je le décris plus bas, la connexion est
exactement la même qu'en IPv4, avec un entête IPv6 en plus, ce qui est
probablement encore mieux que via un tunnel broker.

De plus les relais 6to4 publiques ouverts sont de plus en plus rares.

C'est vrai ? C'est bien dommage. Comment ça se fait ? Il me semblerait
logique que les opérateurs de réseau ayant à la fois de l'IPv6 et de l'IPv4
aient intérêt à mettre ça chez eux, pour raccourcir les routes au maximum,
au contraire. Le coût m'a l'air au mieux nul.

C'est-à-dire ? Peux-tu en dire plus ?

J'ai un tunnel défini par

auto tun6to4
iface tun6to4 inet6 v4tunnel
endpoint any
local 213.41.135.15
up ip -6 route add 2002::/16 via ::192.88.99.1 dev tun6to4 metric 1
mtu 1472

et les outils ifupdown de Debian, ce qui crée le tunnel (qui n'est
d'ailleurs pas vraiment spécifique 6to4), mais sans lui attribuer d'adresse
IP. Le tunnel est configuré comme route par défaut vers 2002::/16, via
192.88.99.1, comme en 6to4, mais c'est inutile, car :

/* Returns the embedded IPv4 address if the IPv6 address
comes from 6to4 (RFC 3056) addr space */

static inline u32 try_6to4(struct in6_addr *v6dst)
{
u32 dst = 0;

if (v6dst->s6_addr16[0] == htons(0x2002)) {
/* 6to4 v6 addr has 16 bits prefix, 32 v4addr, 16 SLA, ... */
memcpy(&dst, &v6dst->s6_addr16[1], 4);
}
return dst;
}

Traduction : le driver de tunnel du noyau, quand il rencontre une adresse en
2002::/16, expédie le paquet directement, plutôt que de passer par
l'endpoint normal du tunnel.

De mon côté, c'est tout, avec quelques règles iptables pour assurer que le
routage entre ce tunnel et mon interface publique est bien légitime (je ne
veux pas servir de point d'entrée ouvert, je n'ai pas la bande passante
pour).

Sur les machines qui ont souvent à communiquer avec moi, je mets, ou je
demande à l'administrateur de mettre :

ip -6 route add 2001:7a8:470f::/48 via ::213.41.135.15

Ça fonctionne de manière très satisfaisante.

"TiChou" wrote in message <gniii.20041104143621@florizarre.tichou.org>:

Et parce que d'autre part la
connectivité IPv6 chez un tunnel broker ou en natif est généralement bien
meilleure en terme de bande passante, de latence et de stabilité que via un
relais 6to4.

Un tunnel broker, ça donne une connexion point à point, c'est bien ça ?
(si ce n'est pas ça, merci d'ignorer le paragraphe qui suit, et de me
corriger)

Dans ce cas, la connexion est certainement meilleure entre le réseau à cette
extrémité et le monde IPv6. En revanche, de 6to4 à 6to4, ou de 6to4 à un
IPv6 avec un routage direct comme je le décris plus bas, la connexion est
exactement la même qu'en IPv4, avec un entête IPv6 en plus, ce qui est
probablement encore mieux que via un tunnel broker.

De plus les relais 6to4 publiques ouverts sont de plus en plus rares.

C'est vrai ? C'est bien dommage. Comment ça se fait ? Il me semblerait
logique que les opérateurs de réseau ayant à la fois de l'IPv6 et de l'IPv4
aient intérêt à mettre ça chez eux, pour raccourcir les routes au maximum,
au contraire. Le coût m'a l'air au mieux nul.

C'est-à-dire ? Peux-tu en dire plus ?

J'ai un tunnel défini par

auto tun6to4
iface tun6to4 inet6 v4tunnel
endpoint any
local 213.41.135.15
up ip -6 route add 2002::/16 via ::192.88.99.1 dev tun6to4 metric 1
mtu 1472

et les outils ifupdown de Debian, ce qui crée le tunnel (qui n'est
d'ailleurs pas vraiment spécifique 6to4), mais sans lui attribuer d'adresse
IP. Le tunnel est configuré comme route par défaut vers 2002::/16, via
192.88.99.1, comme en 6to4, mais c'est inutile, car :

/* Returns the embedded IPv4 address if the IPv6 address
comes from 6to4 (RFC 3056) addr space */

static inline u32 try_6to4(struct in6_addr *v6dst)
{
u32 dst = 0;

if (v6dst->s6_addr16[0] == htons(0x2002)) {
/* 6to4 v6 addr has 16 bits prefix, 32 v4addr, 16 SLA, ... */
memcpy(&dst, &v6dst->s6_addr16[1], 4);
}
return dst;
}

Traduction : le driver de tunnel du noyau, quand il rencontre une adresse en
2002::/16, expédie le paquet directement, plutôt que de passer par
l'endpoint normal du tunnel.

De mon côté, c'est tout, avec quelques règles iptables pour assurer que le
routage entre ce tunnel et mon interface publique est bien légitime (je ne
veux pas servir de point d'entrée ouvert, je n'ai pas la bande passante
pour).

Sur les machines qui ont souvent à communiquer avec moi, je mets, ou je
demande à l'administrateur de mettre :

ip -6 route add 2001:7a8:470f::/48 via ::213.41.135.15

Ça fonctionne de manière très satisfaisante.

Vous avez filtré cet utilisateur ! Consultez son message

"TiChou" wrote in message :

Et parce que d'autre part la
connectivité IPv6 chez un tunnel broker ou en natif est généralement bien
meilleure en terme de bande passante, de latence et de stabilité que via un
relais 6to4.

Un tunnel broker, ça donne une connexion point à point, c'est bien ça ?
(si ce n'est pas ça, merci d'ignorer le paragraphe qui suit, et de me
corriger)

Dans ce cas, la connexion est certainement meilleure entre le réseau à cette
extrémité et le monde IPv6. En revanche, de 6to4 à 6to4, ou de 6to4 à un
IPv6 avec un routage direct comme je le décris plus bas, la connexion est
exactement la même qu'en IPv4, avec un entête IPv6 en plus, ce qui est
probablement encore mieux que via un tunnel broker.

De plus les relais 6to4 publiques ouverts sont de plus en plus rares.

C'est vrai ? C'est bien dommage. Comment ça se fait ? Il me semblerait
logique que les opérateurs de réseau ayant à la fois de l'IPv6 et de l'IPv4
aient intérêt à mettre ça chez eux, pour raccourcir les routes au maximum,
au contraire. Le coût m'a l'air au mieux nul.

C'est-à-dire ? Peux-tu en dire plus ?

J'ai un tunnel défini par

auto tun6to4
iface tun6to4 inet6 v4tunnel
endpoint any
local 213.41.135.15
up ip -6 route add 2002::/16 via ::192.88.99.1 dev tun6to4 metric 1
mtu 1472

et les outils ifupdown de Debian, ce qui crée le tunnel (qui n'est
d'ailleurs pas vraiment spécifique 6to4), mais sans lui attribuer d'adresse
IP. Le tunnel est configuré comme route par défaut vers 2002::/16, via
192.88.99.1, comme en 6to4, mais c'est inutile, car :

/* Returns the embedded IPv4 address if the IPv6 address
comes from 6to4 (RFC 3056) addr space */

static inline u32 try_6to4(struct in6_addr *v6dst)
{
u32 dst = 0;

if (v6dst->s6_addr16[0] == htons(0x2002)) {
/* 6to4 v6 addr has 16 bits prefix, 32 v4addr, 16 SLA, ... */
memcpy(&dst, &v6dst->s6_addr16[1], 4);
}
return dst;
}

Traduction : le driver de tunnel du noyau, quand il rencontre une adresse en
2002::/16, expédie le paquet directement, plutôt que de passer par
l'endpoint normal du tunnel.

De mon côté, c'est tout, avec quelques règles iptables pour assurer que le
routage entre ce tunnel et mon interface publique est bien légitime (je ne
veux pas servir de point d'entrée ouvert, je n'ai pas la bande passante
pour).

Sur les machines qui ont souvent à communiquer avec moi, je mets, ou je
demande à l'administrateur de mettre :

ip -6 route add 2001:7a8:470f::/48 via ::213.41.135.15

Ça fonctionne de manière très satisfaisante.

Nicolas George

04/11/2004 à 21:22

Nicolas George wrote in message <cme16e$bia$:

Il me semblerait
logique que les opérateurs de réseau ayant à la fois de l'IPv6 et de l'IPv4
aient intérêt à mettre ça chez eux, pour raccourcir les routes au maximum,
au contraire. Le coût m'a l'air au mieux nul.

Bon, cette remarque était débile, c'est dans l'autre sens que c'est
important.

TiChou

04/11/2004 à 22:53

Dans le message <news:cme16e$bia$,
*Nicolas George* tapota sur f.c.o.l.configuration :

Un tunnel broker, ça donne une connexion point à point, c'est bien ça ?

Oui, un tunnel entre toi et ton fournisseur IPv6.

Dans ce cas, la connexion est certainement meilleure entre le réseau à
cette extrémité et le monde IPv6.

Tout à fait.

En revanche, de 6to4 à 6to4, ou de 6to4 à un IPv6 avec un routage direct
comme je le décris plus bas, la connexion est exactement la même qu'en
IPv4,
avec un entête IPv6 en plus, ce qui est probablement encore mieux que via
un
tunnel broker.

Exact. L'intérêt ici du 6to4 est d'avoir une connectivité IPv6 entre
différents POP et non pas sûr le « monde IPv6 » pour te citer. Mais c'est un
intérêt que je reconnais être non négligeable surtout avec ce que tu décris
par la suite.

C'est-à-dire ? Peux-tu en dire plus ?

J'ai un tunnel défini par

auto tun6to4
iface tun6to4 inet6 v4tunnel
endpoint any
local 213.41.135.15
up ip -6 route add 2002::/16 via ::192.88.99.1 dev tun6to4 metric 1
mtu 1472

et les outils ifupdown de Debian, ce qui crée le tunnel (qui n'est
d'ailleurs pas vraiment spécifique 6to4), mais sans lui attribuer
d'adresse IP. Le tunnel est configuré comme route par défaut vers
2002::/16,
via 192.88.99.1, comme en 6to4, mais c'est inutile, car :

[code source]

Traduction : le driver de tunnel du noyau, quand il rencontre une adresse
en 2002::/16, expédie le paquet directement, plutôt que de passer par
l'endpoint normal du tunnel.

Et bien tu m'apprends quelque chose de fort intéressant sur cette
particularité du noyau que j'aurais depuis le temps du deviner ou connaître
!

Sur les machines qui ont souvent à communiquer avec moi, je mets, ou je
demande à l'administrateur de mettre :

ip -6 route add 2001:7a8:470f::/48 via ::213.41.135.15

$ ip tunnel add 6to4 mode sit local 212.11.35.166
$ ip link set 6to4 up
$ ip route add 2002::/16 dev 6to4

Je viens de faire rapidement un test et d'analyser cela avec tcpdump.
$ ping6 2002:52e1:6c2b::1 (52e1:6c2b = 82.225.108.43)

» 22:40:02.549916 IP 212.11.35.166 > 82.225.108.43: ::212.11.35.166 >
2002:52e1:6c2b::1: icmp6: echo request seq 1

Ça fonctionne de manière très satisfaisante.

Oui, effectivement le résultat est très concluant ! :)

--
TiChou

Dans le message <news:cme16e$bia$1@biggoron.nerim.net>,
*Nicolas George* tapota sur f.c.o.l.configuration :

Un tunnel broker, ça donne une connexion point à point, c'est bien ça ?

Oui, un tunnel entre toi et ton fournisseur IPv6.

Dans ce cas, la connexion est certainement meilleure entre le réseau à
cette extrémité et le monde IPv6.

Tout à fait.

En revanche, de 6to4 à 6to4, ou de 6to4 à un IPv6 avec un routage direct
comme je le décris plus bas, la connexion est exactement la même qu'en
IPv4,
avec un entête IPv6 en plus, ce qui est probablement encore mieux que via
un
tunnel broker.

Exact. L'intérêt ici du 6to4 est d'avoir une connectivité IPv6 entre
différents POP et non pas sûr le « monde IPv6 » pour te citer. Mais c'est un
intérêt que je reconnais être non négligeable surtout avec ce que tu décris
par la suite.

C'est-à-dire ? Peux-tu en dire plus ?

J'ai un tunnel défini par

auto tun6to4
iface tun6to4 inet6 v4tunnel
endpoint any
local 213.41.135.15
up ip -6 route add 2002::/16 via ::192.88.99.1 dev tun6to4 metric 1
mtu 1472

et les outils ifupdown de Debian, ce qui crée le tunnel (qui n'est
d'ailleurs pas vraiment spécifique 6to4), mais sans lui attribuer
d'adresse IP. Le tunnel est configuré comme route par défaut vers
2002::/16,
via 192.88.99.1, comme en 6to4, mais c'est inutile, car :

[code source]

Traduction : le driver de tunnel du noyau, quand il rencontre une adresse
en 2002::/16, expédie le paquet directement, plutôt que de passer par
l'endpoint normal du tunnel.

Et bien tu m'apprends quelque chose de fort intéressant sur cette
particularité du noyau que j'aurais depuis le temps du deviner ou connaître
!

Sur les machines qui ont souvent à communiquer avec moi, je mets, ou je
demande à l'administrateur de mettre :

ip -6 route add 2001:7a8:470f::/48 via ::213.41.135.15

$ ip tunnel add 6to4 mode sit local 212.11.35.166
$ ip link set 6to4 up
$ ip route add 2002::/16 dev 6to4

Je viens de faire rapidement un test et d'analyser cela avec tcpdump.
$ ping6 2002:52e1:6c2b::1 (52e1:6c2b = 82.225.108.43)

» 22:40:02.549916 IP 212.11.35.166 > 82.225.108.43: ::212.11.35.166 >
2002:52e1:6c2b::1: icmp6: echo request seq 1

Ça fonctionne de manière très satisfaisante.

Oui, effectivement le résultat est très concluant ! :)

--
TiChou

Vous avez filtré cet utilisateur ! Consultez son message

Dans le message <news:cme16e$bia$,
*Nicolas George* tapota sur f.c.o.l.configuration :

Un tunnel broker, ça donne une connexion point à point, c'est bien ça ?

Oui, un tunnel entre toi et ton fournisseur IPv6.

Dans ce cas, la connexion est certainement meilleure entre le réseau à
cette extrémité et le monde IPv6.

Tout à fait.

En revanche, de 6to4 à 6to4, ou de 6to4 à un IPv6 avec un routage direct
comme je le décris plus bas, la connexion est exactement la même qu'en
IPv4,
avec un entête IPv6 en plus, ce qui est probablement encore mieux que via
un
tunnel broker.

Exact. L'intérêt ici du 6to4 est d'avoir une connectivité IPv6 entre
différents POP et non pas sûr le « monde IPv6 » pour te citer. Mais c'est un
intérêt que je reconnais être non négligeable surtout avec ce que tu décris
par la suite.

C'est-à-dire ? Peux-tu en dire plus ?

J'ai un tunnel défini par

auto tun6to4
iface tun6to4 inet6 v4tunnel
endpoint any
local 213.41.135.15
up ip -6 route add 2002::/16 via ::192.88.99.1 dev tun6to4 metric 1
mtu 1472

et les outils ifupdown de Debian, ce qui crée le tunnel (qui n'est
d'ailleurs pas vraiment spécifique 6to4), mais sans lui attribuer
d'adresse IP. Le tunnel est configuré comme route par défaut vers
2002::/16,
via 192.88.99.1, comme en 6to4, mais c'est inutile, car :

[code source]

Traduction : le driver de tunnel du noyau, quand il rencontre une adresse
en 2002::/16, expédie le paquet directement, plutôt que de passer par
l'endpoint normal du tunnel.

Et bien tu m'apprends quelque chose de fort intéressant sur cette
particularité du noyau que j'aurais depuis le temps du deviner ou connaître
!

Sur les machines qui ont souvent à communiquer avec moi, je mets, ou je
demande à l'administrateur de mettre :

ip -6 route add 2001:7a8:470f::/48 via ::213.41.135.15

$ ip tunnel add 6to4 mode sit local 212.11.35.166
$ ip link set 6to4 up
$ ip route add 2002::/16 dev 6to4

Je viens de faire rapidement un test et d'analyser cela avec tcpdump.
$ ping6 2002:52e1:6c2b::1 (52e1:6c2b = 82.225.108.43)

» 22:40:02.549916 IP 212.11.35.166 > 82.225.108.43: ::212.11.35.166 >
2002:52e1:6c2b::1: icmp6: echo request seq 1

Ça fonctionne de manière très satisfaisante.

Oui, effectivement le résultat est très concluant ! :)

--
TiChou

TiChou

04/11/2004 à 22:55

(supersedes )

Dans le message <news:cme16e$bia$,
*Nicolas George* tapota sur f.c.o.l.configuration :

Un tunnel broker, ça donne une connexion point à point, c'est bien ça ?

Oui, un tunnel entre toi et ton fournisseur IPv6.

Dans ce cas, la connexion est certainement meilleure entre le réseau à
cette extrémité et le monde IPv6.

Tout à fait.

En revanche, de 6to4 à 6to4, ou de 6to4 à un IPv6 avec un routage direct
comme je le décris plus bas, la connexion est exactement la même qu'en
IPv4,
avec un entête IPv6 en plus, ce qui est probablement encore mieux que via
un
tunnel broker.

Exact. L'intérêt ici du 6to4 est d'avoir une connectivité IPv6 entre
différents POP et non pas sûr le « monde IPv6 » pour te citer. Mais c'est un
intérêt que je reconnais être non négligeable surtout avec ce que tu décris
par la suite.

C'est-à-dire ? Peux-tu en dire plus ?

J'ai un tunnel défini par

auto tun6to4
iface tun6to4 inet6 v4tunnel
endpoint any
local 213.41.135.15
up ip -6 route add 2002::/16 via ::192.88.99.1 dev tun6to4 metric 1
mtu 1472

et les outils ifupdown de Debian, ce qui crée le tunnel (qui n'est
d'ailleurs pas vraiment spécifique 6to4), mais sans lui attribuer
d'adresse IP. Le tunnel est configuré comme route par défaut vers
2002::/16,
via 192.88.99.1, comme en 6to4, mais c'est inutile, car :

[code source]

Traduction : le driver de tunnel du noyau, quand il rencontre une adresse
en 2002::/16, expédie le paquet directement, plutôt que de passer par
l'endpoint normal du tunnel.

Et bien tu m'apprends quelque chose de fort intéressant sur cette
particularité du noyau que j'aurais depuis le temps du deviner ou
connaître !

Sur les machines qui ont souvent à communiquer avec moi, je mets, ou je
demande à l'administrateur de mettre :

ip -6 route add 2001:7a8:470f::/48 via ::213.41.135.15

Je viens de faire rapidement un test et d'analyser cela avec tcpdump.

$ ip tunnel add 6to4 mode sit local 212.11.35.166
$ ip link set 6to4 up
$ ip route add 2002::/16 dev 6to4

$ ping6 2002:52e1:6c2b::1 (52e1:6c2b = 82.225.108.43)

» 22:40:02.549916 IP 212.11.35.166 > 82.225.108.43: ::212.11.35.166 >
2002:52e1:6c2b::1: icmp6: echo request seq 1

Ça fonctionne de manière très satisfaisante.

Oui, effectivement le résultat est très concluant ! :)

--
TiChou

(supersedes <bzium.20041104222551@florizarre.tichou.org>)

Dans le message <news:cme16e$bia$1@biggoron.nerim.net>,
*Nicolas George* tapota sur f.c.o.l.configuration :

Un tunnel broker, ça donne une connexion point à point, c'est bien ça ?

Oui, un tunnel entre toi et ton fournisseur IPv6.

Dans ce cas, la connexion est certainement meilleure entre le réseau à
cette extrémité et le monde IPv6.

Tout à fait.

En revanche, de 6to4 à 6to4, ou de 6to4 à un IPv6 avec un routage direct
comme je le décris plus bas, la connexion est exactement la même qu'en
IPv4,
avec un entête IPv6 en plus, ce qui est probablement encore mieux que via
un
tunnel broker.

Exact. L'intérêt ici du 6to4 est d'avoir une connectivité IPv6 entre
différents POP et non pas sûr le « monde IPv6 » pour te citer. Mais c'est un
intérêt que je reconnais être non négligeable surtout avec ce que tu décris
par la suite.

C'est-à-dire ? Peux-tu en dire plus ?

J'ai un tunnel défini par

auto tun6to4
iface tun6to4 inet6 v4tunnel
endpoint any
local 213.41.135.15
up ip -6 route add 2002::/16 via ::192.88.99.1 dev tun6to4 metric 1
mtu 1472

et les outils ifupdown de Debian, ce qui crée le tunnel (qui n'est
d'ailleurs pas vraiment spécifique 6to4), mais sans lui attribuer
d'adresse IP. Le tunnel est configuré comme route par défaut vers
2002::/16,
via 192.88.99.1, comme en 6to4, mais c'est inutile, car :

[code source]

Traduction : le driver de tunnel du noyau, quand il rencontre une adresse
en 2002::/16, expédie le paquet directement, plutôt que de passer par
l'endpoint normal du tunnel.

Et bien tu m'apprends quelque chose de fort intéressant sur cette
particularité du noyau que j'aurais depuis le temps du deviner ou
connaître !

Sur les machines qui ont souvent à communiquer avec moi, je mets, ou je
demande à l'administrateur de mettre :

ip -6 route add 2001:7a8:470f::/48 via ::213.41.135.15

Je viens de faire rapidement un test et d'analyser cela avec tcpdump.

$ ip tunnel add 6to4 mode sit local 212.11.35.166
$ ip link set 6to4 up
$ ip route add 2002::/16 dev 6to4

$ ping6 2002:52e1:6c2b::1 (52e1:6c2b = 82.225.108.43)

» 22:40:02.549916 IP 212.11.35.166 > 82.225.108.43: ::212.11.35.166 >
2002:52e1:6c2b::1: icmp6: echo request seq 1

Ça fonctionne de manière très satisfaisante.

Oui, effectivement le résultat est très concluant ! :)

--
TiChou

Vous avez filtré cet utilisateur ! Consultez son message

(supersedes )

Dans le message <news:cme16e$bia$,
*Nicolas George* tapota sur f.c.o.l.configuration :

Un tunnel broker, ça donne une connexion point à point, c'est bien ça ?

Oui, un tunnel entre toi et ton fournisseur IPv6.

Dans ce cas, la connexion est certainement meilleure entre le réseau à
cette extrémité et le monde IPv6.

Tout à fait.

En revanche, de 6to4 à 6to4, ou de 6to4 à un IPv6 avec un routage direct
comme je le décris plus bas, la connexion est exactement la même qu'en
IPv4,
avec un entête IPv6 en plus, ce qui est probablement encore mieux que via
un
tunnel broker.

Exact. L'intérêt ici du 6to4 est d'avoir une connectivité IPv6 entre
différents POP et non pas sûr le « monde IPv6 » pour te citer. Mais c'est un
intérêt que je reconnais être non négligeable surtout avec ce que tu décris
par la suite.

C'est-à-dire ? Peux-tu en dire plus ?

J'ai un tunnel défini par

auto tun6to4
iface tun6to4 inet6 v4tunnel
endpoint any
local 213.41.135.15
up ip -6 route add 2002::/16 via ::192.88.99.1 dev tun6to4 metric 1
mtu 1472

et les outils ifupdown de Debian, ce qui crée le tunnel (qui n'est
d'ailleurs pas vraiment spécifique 6to4), mais sans lui attribuer
d'adresse IP. Le tunnel est configuré comme route par défaut vers
2002::/16,
via 192.88.99.1, comme en 6to4, mais c'est inutile, car :

[code source]

Traduction : le driver de tunnel du noyau, quand il rencontre une adresse
en 2002::/16, expédie le paquet directement, plutôt que de passer par
l'endpoint normal du tunnel.

Et bien tu m'apprends quelque chose de fort intéressant sur cette
particularité du noyau que j'aurais depuis le temps du deviner ou
connaître !

Sur les machines qui ont souvent à communiquer avec moi, je mets, ou je
demande à l'administrateur de mettre :

ip -6 route add 2001:7a8:470f::/48 via ::213.41.135.15

Je viens de faire rapidement un test et d'analyser cela avec tcpdump.

$ ip tunnel add 6to4 mode sit local 212.11.35.166
$ ip link set 6to4 up
$ ip route add 2002::/16 dev 6to4

$ ping6 2002:52e1:6c2b::1 (52e1:6c2b = 82.225.108.43)

» 22:40:02.549916 IP 212.11.35.166 > 82.225.108.43: ::212.11.35.166 >
2002:52e1:6c2b::1: icmp6: echo request seq 1

Ça fonctionne de manière très satisfaisante.

Oui, effectivement le résultat est très concluant ! :)

--
TiChou

Pascal

05/11/2004 à 00:55

TiChou wrote:

Alors, il y a un truc qui m'échappe ou bien ces interfaces seraient
inutilisables [...] ?

Effectivement, ces interfaces virtuelles ne peuvent pas être affectées
au montage de tunnels classiques.
C'est de toute manière des interfaces qu'on recommande de ne plus utiliser.

C'est qui "on", et où est-ce dit ? Comment les utilisait-on ? Comme je
le disais, je n'ai rien trouvé.

Par exemple, on utilisait auparavant l'interface IPv6 sit0 pour faire de
façon simple du 6to4. On configurait les adresses IPv6 sur cette
interface et on créait une simple route vers un routeur sachant faire du
6to4.

Et pour les deux autres types ?
En fait, comme j'ai la chance d'avoir de l'IPv6 natif à la maison, je me
suis très peu penché sur les tunnels sit. Toutefois j'ai lu avec intérêt
la suite de la discussion engagée avec Nicolas, et je n'ai pas tout
saisi. L'heure tardive, sans doute. Je relirai tout ça à tête reposée et
reviendrai sans doute avec d'autres questions.

TiChou

06/11/2004 à 13:03

Dans le message <news:cmeff8$im3$,
** tapota sur f.c.o.l.configuration :

Alors, il y a un truc qui m'échappe ou bien ces interfaces seraient
inutilisables [...] ?

Effectivement, ces interfaces virtuelles ne peuvent pas être affectées au
montage de tunnels classiques.
C'est de toute manière des interfaces qu'on recommande de ne plus
utiliser.

C'est qui "on", et où est-ce dit ? Comment les utilisait-on ? Comme je le
disais, je n'ai rien trouvé.

Il est vrai qu'on ne trouve pas (ou plus ?) grand chose sur le sujet.
Pour l'interface sit0, vous avez le Linux IPv6 HowTo de Bieringer qui en
parle un peu et qui dit qu'effectivement que l'utilisation de sit0 est
« deprecated ».
Pour les autres je n'ai rien trouvé d'intéressant.

--
TiChou

Tunnels gre0, sit0, tunl0

9 réponses

Veuillez sélectionner un problème