Freebox Server (Ultra V9/ Pop V8/ Delta V7 / Revolution V6 / Mini 4K)

Concerne le projet: Freebox Server (Ultra V9/ Pop V8/ Delta V7 / Revolution V6 / Mini 4K)
Ouverte par Fuli10 - 08/03/2016
Dernière modification par mbizon - 08/03/2016

Bonjour,

Je suis en VDSL avec une encapsulation 6rd pour l’IPv6. J’utilise mon propre routeur configuré en dual-stack pour gérer l’IPv6.
Donc pour accéder à internet en IPv6, la freebox retourne une MTU de 1480. Pour accéder au réseau local en IPv6, la MTU donnée par le routeur est 1500.
Le routeur redistribuant les paquets “ICMP6 too big” aux clients, ils n’ont aucun problème pour accéder au net avec la bonne MTU.

Le seul “souci” est dans le lien en direct à la freebox en IPv6 (interface web, test débit local, NAS, etc.) avec un protocole autre que TCP (UDP, ICMP).
En effet, les clients peuvent y accéder avec une MTU de 1500 et à priori la freebox ne retourne à aucun moment de paquet “ICMP6 too big”, même si elle fragmente la réponse.
Autant en TCP le MSS clamping permet de ne pas avoir de problème, autant en ICMP (et UDP aussi je suppose) il peut y avoir des petits problèmes de fragmentation.
Capture du premier paquet d’un ping sur la freebox d’un paquet ICMP de 1433 octets (1 octet de plus que permet une MTU de 1480):

$ sudo tcpdump -nai eth0 ip6
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
16:50:48.212663 IP6 2a01:xx::xx > fd0f:ee:b0::1: ICMP6, echo request, seq 1, length 1441
16:50:48.213012 IP6 fd0f:ee:b0::1 > 2a01:xx::xx: frag (0|1432) ICMP6, echo reply, seq 1, length 1432
16:50:48.213070 IP6 fd0f:ee:b0::1 > 2a01:xx::xx: frag (1432|9)

La même chose sur un serveur IPv6 supportant la fragmentation:

$ sudo tcpdump -nai eth0 ip6
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
17:26:21.358569 IP6 2a01:xx::xx > 2a02:348:82:cb69::1: ICMP6, echo request, seq 1, length 1441
**17:26:21.358929 IP6 2a01:<freebox>::1 > 2a01:xx::xx: ICMP6, packet too big, mtu 1480, length 1240**
17:26:22.360669 IP6 2a01:xx::xx > 2a02:348:82:cb69::1: frag (0|1432) ICMP6, echo request, seq 2, length 1432
17:26:22.360764 IP6 2a01:xx::xx > 2a02:348:82:cb69::1: frag (1432|9)
17:26:22.390095 IP6 2a02:348:82:cb69::1 > 2a01:xx::xx: frag (0|1432) ICMP6, echo reply, seq 2, length 1432
17:26:22.390166 IP6 2a02:348:82:cb69::1 > 2a01:xx::xx: frag (1432|9)
17:26:23.362660 IP6 2a01:xx::xx > 2a02:348:82:cb69::1: frag (0|1432) ICMP6, echo request, seq 3, length 1432
17:26:23.362758 IP6 2a01:xx::xx > 2a02:348:82:cb69::1: frag (1432|9)
17:26:23.391572 IP6 2a02:348:82:cb69::1 > 2a01:xx::xx: frag (0|1432) ICMP6, echo reply, seq 3, length 1432
17:26:23.391637 IP6 2a02:348:82:cb69::1 > 2a01:xx::xx: frag (1432|9)

En gros:
- la box répond bien à un paquet lui étant destiné, même si le paquet est trop grand par rapport à sa MTU (1480)
- la réponse est fragmentée (soit !)
- ce qui en soit n’est pas choquant, la MTU de l’interface en IPv6 devant être forcé à 1480 je suppose par son ravd interne
- mais à AUCUN moment je n’ai eu un ICMP too big ⇒ ça ce n’est pas normal
Le même tcpdump sur ping trop grand vers un serveur internet qui l’accepte (www.subnetonline.com) montre bien que la freebox retourne un “ICMP6, packet too big”, mais quelle fragmente bien le request car je vois également les fragments de reply arriver.
A mon avis, quand on accède à une IPv6 de la Freebox avec un paquet trop grand:
- soit la freebox doit retourner un ICMP too big en plus de ses fragments
- soit elle doit être capable de répondre sans fragmenter
Voila, c’est à mon avis un petit bug qui va être vite corrigé.