Le protocole
Le format des en-têtes GRE (
D'abord, le cas où IPv6 est la charge utile (section 3 de notre
RFC), encapsulé
dans... ce qu'on veut, IPv4 ou IPv6. Dans l'en-tête GRE, le champ
Qui dit
En théorie, une mise en œuvre standard de GRE doit tester cette
possibilité, avant d'envoyer des paquets IPv6. (Celles
d'aujourd'hui ne le font apparemment pas souvent, cf.
Et si le point d'entrée du tunnel GRE reçoit un paquet qui est
plus grand que la MTU du tunnel ? Rappelez-vous qu'une des
principales différences entre IPv4 et IPv6 est que, en IPv6, les
Et le contraire, IPv6 comme réseau sous-jacent, pour
transporter n'importe quoi, de l'IPv4 ou de l'IPv6 (section 4 de
notre RFC) ? Le paquet IPv6 va comporter l'en-tête IPv6, zéro, un
ou davantage en-têtes d'extensions, puis la charge utile, faite
d'un en-tête GRE et des données (un paquet IPv4 ou IPv6). S'il n'y
a pas d'en-têtes d'extension IPv6, le champ
Comme l'en-tête IPv6 n'a pas de somme de contrôle, une distribution du paquet à la mauvaise machine est toujours possible. Le comportement normal de cette machine qui reçoit un paquet inattendu est de le jeter silencieusement. Si elle parle GRE elle-même, elle peut faire la décapsulation et faire suivre le paquet (cela me semble très dangereux, permettant de faire relayer les paquets par des machines « ouvertes »).
Enfin, la section 6 de notre RFC se penche sur la sécurité de
GRE. Cela va vite car elle est à peu près nulle (cf.
Comme indiqué plus haut, il existe déjà plusieurs mises en
œuvre de GRE IPv6. Faisons quelques essais avec des machines
% sudo ip tunnel add tun0 mode gre remote 10.254.112.180 \
local 192.168.43.49 ttl 255
% sudo ip link set tun0 up
On a ici créé un tunnel GRE entre la machine locale,
% sudo ip -6 addr add fda1:1a36:de6d::2 dev tun0
% sudo ip -6 route add fda1:1a36:de6d::/48 dev tun0
On fait pareil de l'autre côté du tunnel (en inversant évidemment
% ping6 fda1:1a36:de6d::2
PING fda1:1a36:de6d::2(fda1:1a36:de6d::2) 56 data bytes
64 bytes from fda1:1a36:de6d::2: icmp_seq=1 ttl=64 time=1.22 ms
64 bytes from fda1:1a36:de6d::2: icmp_seq=2 ttl=64 time=0.761 ms
64 bytes from fda1:1a36:de6d::2: icmp_seq=3 ttl=64 time=0.689 ms
^C
--- fda1:1a36:de6d::2 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 0.689/0.893/1.229/0.239 ms
Plus amusant,
16:46:02.240707 IP 10.254.112.180 > 192.168.43.49: GREv0, length 108: \
IP6 fda1:1a36:de6d::1 > fda1:1a36:de6d::2: ICMP6, echo request, seq 1, length 64
16:46:02.240957 IP 192.168.43.49 > 10.254.112.180: GREv0, length 108: \
IP6 fda1:1a36:de6d::2 > fda1:1a36:de6d::1: ICMP6, echo reply, seq 1, length 64
tcpdump a décapsulé le GRE, trouvé les paquets
Essayons maintenant l'inverse, «
% sudo ip -6 tunnel add tun0 mode ip6gre remote 2001:db8:2:245b::42 \
local 2001:db8:8bd9:8bb0:666:6c7c:9bed:b390 ttl 255
% sudo ip -6 link set tun0 up
Donnons des adresses IPv4 :
% sudo ip addr add 172.17.0.2 dev tun0
% sudo ip route add 172.17.0.0/24 dev tun0
Et on peut désormais pinguer en IPv4. tcpdump, là encore, sait
décapsuler et afficher ce qui se passe dans le tunnel :
21:19:17.158171 IP6 2001:db8:2:245b::42 > 2001:db8:8bd9:8bb0:666:6c7c:9bed:b390: GREv0, length 88: \
IP 172.17.0.1 > 172.17.0.2: ICMP echo request, id 32762, seq 1, length 64
21:19:17.238950 IP6 2001:db8:8bd9:8bb0:666:6c7c:9bed:b390 > 2001:db8:2:245b::42: GREv0, length 88: \
IP 172.17.0.2 > 172.17.0.1: ICMP echo reply, id 32762, seq 1, length 64