Forums - Bbox-Mag

Bonjour,

J'ai une interrogation concernant le comportement de la bbox en IPv6.

Sans DHCP6-PD : ca semble bien marcher.

L'activation des DHCP6-PD se fait bien sur la bbox, mes routeurs attrapent bien une delegation de prefix avec des reseaux /64 gerables localement. Tout se configure tout seul : c'est "magique"! Le seul truc enervant reste la limitation a 3 PDs alors qu'on pourrait en avoir 15 !

C'est testé avec un résau Mesh de DECOs (TP-link) et avec un routeur sur lequel j'ai un controle total.

Problème : la Bbox ne renvoie pas le flux en retour sur toute connection vers l'exterieur. Meme avec un simple ping (icmp6 echo req) je nevois pas passer de retour (icmp6 echo reply). Je peux faire un dump en live sur les interfaces de mon routeur et je vois tout passer en temps reel avant filtrage par le firewall.

J'ai testé ca avec firewall, sans firewall, regles simples, regles complexes, etc rien n'y fait. Mais ca semble venir coté Bbox quand je sniffe mes interfaces. On dirait que le uRPF (unicast reverse path forwarding/filtering) est reglé pour ne faire passer les datas uniquement sur le reseau configuré en sortie de la bbox et pas sur les delegations. J'aussi testé ca en PD simple par routeur, et en PDs multiples par routeur : pas de changement : ce n'est pas un effet de MAC comme chez Orange.

Ou alors c'est un blocage interne sur la delegation propre a la bbox qui semble avoir sa propre delegation en /64 (IPv6 publiques interne et externe differentes)

Ca dit quelque chose à quelqu'un ? Merci !

Le Grompf.

Bonjour,

1. Hypothèse la plus probable : absence de route de retour pour les préfixes délégués
C'est le bug le plus fréquent sur les CPE grand public avec DHCPv6-PD. Le flux est le suivant :

Hôte (préfixe délégué /64) → routeur downstream → Bbox → Internet
↓
Internet → Bbox → ??? (la Bbox ne sait pas où envoyer)

La Bbox reçoit bien le /56 ou /60 de Bouygues Telecom, mais au moment où elle délègue un sous-/64, elle devrait installer une route de retour (ip6route add <prefix_délégué>/64 via <link-local_du_routeur_downstream>). Beaucoup de firmwares CPE implémentent DHCPv6-PD côté serveur mais omettent l'injection de route statique côté table de routage interne. Résultat : le trafic retour arrive sur la Bbox (qui connaît le /56 global) puis est blackholé faute de route plus spécifique vers le downstream.
Test de confirmation : Si tu as accès à l'interface de debug de ton routeur downstream, vérifie si la Bbox répond au NDP (Neighbor Discovery) pour les adresses de ton /64 délégué. Si elle répond par un "Neighbor Advertisement" pour des adresses qui ne lui appartiennent pas, elle fait du NDP proxy mal configuré — autre piste ci-dessous.

2. uRPF strict — hypothèse valide mais sur le mauvais sens
Le uRPF strict sur l'interface WAN de la Bbox filtrerait le trafic entrant depuis Internet dont la source ne correspond pas à une route connue via cette interface. Il n'affecte pas directement le routage du trafic retour vers les préfixes délégués. Cela dit :

Si Bouygues Telecom applique du uRPF strict côté BAS (réseau d'accès), ton trafic sortant avec comme source une adresse de préfixe délégué non annoncé dans la table de routage de l'opérateur pourrait être droppé à l'entrée du réseau BT, avant même d'atteindre Internet. Ce serait visible : le ping sortirait mais l'echo reply n'arriverait jamais, même si le hop internet cible n'a aucune raison de refuser.
Bouygues Telecom utilise effectivement du filtering anti-spoofing, et si la Bbox n'annonce pas les préfixes délégués en amont (pas de BGP évidemment, mais pas de mécanisme équivalent en DHCPv6 relay/signaling vers le BAS), le BAS peut considérer les sources depuis tes /64 délégués comme du spoofing.


3. Le cas NDP Proxy mal géré
La Bbox a son propre /64 sur le LAN (SLAAC/EUI-64 pour ses interfaces). Si le firmware implémente un NDP proxy pour les préfixes délégués (au lieu de vraies routes), il y a une race condition classique :

Les sollicitations NDP (Neighbor Solicitation) pour les adresses des préfixes délégués arrivent sur la Bbox
La Bbox fait un proxy NS vers ton routeur downstream
Mais la réponse NA prend trop de temps ou le proxy n'est pas bidirectionnel
Le trafic retour est droppé par timeout NDP

Indice dans ta description : tu mentionnes que la Bbox a des IPv6 publiques interne et externe différentes — c'est cohérent avec une Bbox qui gère son propre /64 de façon isolée et fait du proxy pour le reste plutôt que du routage pur.

4. La limitation à 3 PDs comme indice
La limite de 3 PDs n'est pas un hasard — c'est probablement hardcodé dans le firmware et correspond à une implémentation partielle. Cela suggère que le DHCPv6-PD est une feature ajoutée "par-dessus" un stack IPv6 non conçu pour le routage hiérarchique. Ce type d'implémentation a tendance à avoir exactement le genre de bug de route de retour décrit en §1.

Plan de diagnostic :

1. Sur ton routeur avec contrôle total :
- tcpdump -i <wan_if> -vvv icmp6
- Vérifie si l'echo reply ARRIVE sur l'interface WAN du routeur
→ Si oui : problème firewall/routage local (peu probable vu tes tests)
→ Si non : le problème est en amont (Bbox ou BAS BT)

2. Sur l'interface WAN du routeur, sniffe NDP :
- tcpdump -i <wan_if> -vvv 'icmp6 and (ip6[40] == 135 or ip6[40] == 136)'
- La Bbox fait-elle des NS vers tes adresses délégúees ?
- Si oui → NDP proxy actif → route de retour absente côté Bbox

3. Test de contournement :
- Essaie de configurer une route statique sur la Bbox si l'interface le permet
- Ou active un tunnel 6in4 pour isoler le problème Bbox vs BAS

4. Teste avec un préfixe /64 délégué vs ton propre /64 LAN de la Bbox :
- Depuis un hôte sur le /64 "natif" de la Bbox, le ping6 externe fonctionne-t-il ?
- Si oui : confirme que le problème est spécifique aux préfixes délégués

Hypothèse :
Le problème est très probablement une combinaison de §1 et §2 : la Bbox n'installe pas les routes de retour pour les PDs, et Bouygues Telecom filtre côté BAS les sources depuis des préfixes non signalés. C'est un bug firmware connu sur les Bbox (et d'autres CPE opérateurs) : DHCPv6-PD "fonctionne" côté délégation descendante, mais le chemin retour n'est jamais correctement établi parce que le CPE n'implémente pas la partie "delegating router routing table management" du RFC 3633/8415.

Bonjour,

Voila les resultats des tests du jour...

1. Sur le routeur avec contrôle total : tcpdump -i <wan_if> -vvv icmp6
l'echo reply ARRIVE sur l'interface WAN du routeur : non .
Donc : le problème est en amont (Bbox ou BAS BT)

2. Sur l'interface WAN du routeur : tcpdump -i <wan_if> -vvv 'icmp6 and (ip6[40] == 135 or ip6[40] == 136)'
La Bbox fait des NS vers les adresses délégúees : non, uniquement sur l'adresse WAN native choppée en slaac.

3. Test de contournement :
- configurer une route statique sur la Bbox : L'interface est faite pour de l'IPv4 et re-bricolée facon IPv6 statefull. l'IPv4 maquillé en IPv6 ca enleve toute libertée. Et c'est bon pour le statefull... je n'habite pas dans un sous-marin nucleaire : il y a quelqu'un chez Sagemcom qui merite un bon coup de taser avec ce design bricolomarouflé á la massue.
- tunnel 6in4 pour isoler le problème Bbox vs BAS : oui mais non. je n'ai pas de fournisseur 6to4.

4. Ping6 depuis un hôte sur le /64 "natif" de la Bbox :
Le ping6 fonctionne depuis tout host sur le LAN-Bbox racine prefix 90. (les 3 PD sont en 91,92,93 et le WAN squatte en 9F
Donc ca confirme bien que le problème est spécifique aux préfixes délégués

Et j'ai desactivé le firewall IPv6 de la bbox... niet, nada,queudal coté effet á part attirer des connexions nord-corréennes.

La buggicité semble bien venir du coté BT.
Et ca devient du Cervantes dans le texte... je vais arreter de visiter les moulins !

Bon, etape 1 ... gerer l'autoreset du vendredi/samedi sur cette satanée box wifi 7... (elle va souffrir coté regulateur d'alim, j'espere que BT n'a pas fait d'economies dessus sinon ca va sentir le circuit imprimé brulé dans six mois). étape 2 ... trouver un XGS-GPON autonome ! . Je vais me faire ma GBox aussi appellée GrompfBox

Ca chauffera moins que les 90dg actuels de mon SFP+ 10G RJ45 et ca va fonctionner. D'ailleurs quelle idée ils ont eu de mettre du 10Gbps cuivre ... Ca doit surement être pour reconnaitre les clients á leurs brulures.

A+
Le Grompf.

Bonsoir,

Potentiellement avec ton retour il y a peut être deux anomalies

Test à faire pour éventuellement confirmer les éléments :

Depuis un hôte derrière un PD, lance un traceroute6 vers une cible publique :

bashtraceroute6 -q 1 -N 1 2606:4700:4700::1111

• Si tu vois au moins 1 hop (la Bbox) avant que ça s'arrête → le paquet sort de ton routeur, arrive à la Bbox, mais est droppé là (Bug 1 ou Bug 2 côté egress WAN)
• Si tu ne vois aucun hop du tout → le paquet n'atteint même pas la Bbox (firewall résiduel sur ton routeur, ou Drop avant même NDP)
• Si tu vois 2+ hops → le paquet passe la Bbox et entre dans le réseau BT → Bug 1 uniquement (pas de route retour, ou uRPF BAS)

Et en parallèle, ping6 croisé depuis un hôte :91:: vers un hôte :90:: (LAN natif Bbox) :

bashping6 <adresse_hôte_sur_:90::>

Si ça fonctionne → la Bbox route correctement en interne entre ses interfaces LAN, mais filtre uniquement sur le WAN. Si ça échoue → la table de routage interne est globalement cassée pour les PDs.

tu me feras le retour de ces deux éléments, comme je ne sais plus si j'ai déjà remonté ou pas mais avec cet échange je referai une nouvelle remontée

Après en contournement ce qui pourrait être envisagé :

Option 1 — NPTv6 sur ton routeur downstream (moche mais fonctionnel)
Tu fais de la traduction de préfixe : les hôtes derrière le PD apparaissent avec l'adresse :90:: du LAN natif Bbox vers l'extérieur. Tu perds le end-to-end IPv6 mais tu récupères la connectivité.
Option 2 — Unique Interface ID avec adresse :90::
Sur ton routeur downstream, configure une adresse supplémentaire dans le :90::/64 natif de la Bbox (en plus du PD) comme source préférée pour le trafic sortant. Les hôtes derrière utilisent le PD localement, mais le routeur fait du NAT66 source uniquement pour le WAN.

Bonsoir,

Alors question routage ...

$ doas traceroute6 -q 1 2606:4700:4700::1111
doas (xxx@xxx.grompf.lan) password:
traceroute6 to 2606:4700:4700::1111 (2606:4700:4700::1111), 64 hops max, 60 byte packets
1 2001:861:8c82:fe92::1 (2001:861:8c82:fe92::1) 0.359 ms
64 *
$

et le ping6 ... depuis un :92: vers un :90: , c'est KO

La rustine passe en NAT66. Mais se tartiner du NAT au 21eme siecle ca fait un peu raler.

Bonne soirée

Bonjour,

Parfait merci pour ton retour, je viens de partager notre échange vers nos équipes.

Bonne journée