La Fibre
Télécom => Réseau => 
IPv6 => Discussion démarrée par: renaud07 le 09 mars 2025 à 20:39:39
-
Bonsoir,
J'ai un petit problème avec ce qu'il semble être le nombre maximum d'IPv6 attribuable par défaut à une interface sous Linux (net.ipv6.conf.nic.max_addresses=16)
Ayant un soucis de ligne ADSL, mon routeur 4G a pris le relais. Il y a eu nombreuses coupures à un moment donné avec changement de préfixe, un de mes systèmes a eu 16 IPv6 en même temps et une fois la limite atteinte, il ne prend plus de nouvelles adresses même si un nouveau RA se présente. Ce qui veut dire plus de connexion fonctionnelle tant que je ne supprime pas au moins une adresse manuellement.
Je voudrais donc simplement que toutes les adresses deprecated soient supprimées immédiatement sans attendre le valid lifetime. Mais je n'arrive pas à trouver si une commande ou une conf existe ou s'il faut faire un script maison.
Merci.
-
Bon, j'ai finalement posé la question à copilot : pas de mécanisme intégré directement pour supprimer les adresses deprecated avant l'expiration officielle, la seule solution est d'augmenter le max_adresses, en espérant que ça ne coupe pas trop souvent.
Puis je me suis rappelé que j'avais fait un peu la même chose avec le CLAT (https://lafibre.info/serveur-linux/redemarrer-un-service-avec-systemd/)
J'ai donc réutilisé la commande pour lister les IP deprecated dans un script qui parcours toutes les interfaces :
#!/bin/bash
# Get interfaces list
interfaces=$(ls /sys/class/net)
for interface in $interfaces; do
# Get the list of deprecated IPv6 addresses for each interface
deprecated_ips=$(ip -6 -o addr show deprecated scope global dev $interface | awk '{print $4}')
for ip in $deprecated_ips; do
# Delete deprecated IPv6
sudo ip -6 addr del $ip dev $interface
echo "Deleted deprecated IP: $ip on interface: $interface"
done
done
Plus qu'à mettre ça dans un cron ou systemd et ça devrait être bon.
-
peut-être aussi en envoyant des RA avec un lifetime a 0 pour le/les prefix(es) deprecated ? en utilisant un truc comme https://github.com/fgont/ipv6toolkit ?
l'avantage est que ca diffuse partout plutot que juste traiter le problème sur ta machine.
apres la solution d'un simple script bash a l'avantage de la simplicité ...
-
peut-être aussi en envoyant des RA avec un lifetime a 0 pour le/les prefix(es) deprecated ? en utilisant un truc comme https://github.com/fgont/ipv6toolkit ?
Oui, c'est d'ailleurs ce que font automatiquement les versions récentes de RouterOS quand on change l'adresse IPv6 d'une interface.
-
Petit HS :
Plus je parcours les pages du forum plus je vois que l'ipv6 est en fait une grosse usine à gaz et ça ne fonctionne pas aussi bien nativement comme on se l'imagine
-
Petit HS :
Plus je parcours les pages du forum plus je vois que l'ipv6 est en fait une grosse usine à gaz et ça ne fonctionne pas aussi bien nativement comme on se l'imagine
Non, le souci c'est pas IPv6, c'est l'opérateur teubé qui change le préfixe à chaque coupure.
-
je vois que l'ipv6 est en fait une grosse usine à gaz
C'est sur que le NAT en IPv4, qui oblige à changer les entêtes TCP/UDP et IP de tous les paquets, de recalculer leur checksum, c'est pas une usine à gaz.
-
Merci pour vos réponses.
Le routeur envoie bien un lifetime à 0 avant d’annoncer le nouveau préfixe. Mais les adresses restent jusqu'à la fin du valid llifetime, c'est bien comme ça que c'est censé marcher, non ? Le preferred lifetime est bien à 0 et donc la machine ne les utilise plus (mais essaie d'utiliser une ULA à la place, ce qui évidemment n'aboutit à rien).
Le problème ne se produit que lorsque il y a trop de coupures en 2h et que les préfixes n'ont pas le temps d’expirer, si pas de coupure ou très peu, tout va bien, ça s'efface au fur et à mesure.
Les préfixes sont en 7200 valid - 3600 pref.
EDIT : J'ai un doute @kgersen, tu parles du valid/pref du préfixe à 0 ou celui du routeur ? Car si c'est le préfixe, ça reste à 7200/3600 dans les 2 cas.
-
@renaud07 :
Ces « annonces de routeur » (RA) sont purement rejetées car leur champ (Hop Limit) « Limite de saut » n'est pas égal à 255.
A node MUST silently discard any received Router Advertisement messages that do not satisfy all of the following validity checks:
- The IP Hop Limit field has a value of 255, i.e., the packet could not possibly have been forwarded by a router.
Source : https://www.rfc-editor.org/rfc/rfc4861.html#section-6.1.2
-
Il me semble qu'on ne peut pas « définir » zéro comme durée de validité d'un préfixe (qui apparaît dans l'option d'information de préfixe).
e) If the advertised prefix is equal to the prefix of an address configured by stateless autoconfiguration in the list, the preferred lifetime of
the address is reset to the Preferred Lifetime in the received advertisement.
The specific action to perform for the valid lifetime of the address depends on the Valid Lifetime in the received advertisement and the
remaining time to the valid lifetime expiration of the previously autoconfigured address. We call the remaining time "RemainingLifetime"
in the following discussion:
1. If the received Valid Lifetime is greater than 2 hours or greater than RemainingLifetime, set the valid lifetime of the corresponding
address to the advertised Valid Lifetime.
2. If RemainingLifetime is less than or equal to 2 hours, ignore the Prefix Information option with regards to the valid lifetime, unless
the Router Advertisement from which this option was obtained has been authenticated (e.g., via Secure Neighbor Discovery [RFC3971]).
If the Router Advertisement was authenticated, the valid lifetime of the corresponding address should be set to the Valid Lifetime in
the received option.
3. Otherwise, reset the valid lifetime of the corresponding address to 2 hours.
The above rules address a specific denial-of-service attack in which a bogus advertisement could contain prefixes with very small
Valid Lifetimes. Without the above rules, a single unauthenticated advertisement containing bogus Prefix Information options with
short Valid Lifetimes could cause all of a node’s addresses to expire prematurely. The above rules ensure that legitimate advertisements
(which are sent periodically) will "cancel" the short Valid Lifetimes before they actually take effect.
Note that the preferred lifetime of the corresponding address is always reset to the Preferred Lifetime in the received Prefix Information
option, regardless of whether the valid lifetime is also reset or ignored. The difference comes from the fact that the possible attack for
the preferred lifetime is relatively minor. Additionally, it is even undesirable to ignore the preferred lifetime when a valid administrator
wants to deprecate a particular address by sending a short preferred lifetime (and the valid lifetime is ignored by accident).
Source : https://www.rfc-editor.org/rfc/rfc4862#section-5.5.3
-
Ayant un soucis de ligne ADSL, mon routeur 4G a pris le relais. Il y a eu nombreuses coupures à un moment donné avec changement de préfixe, un de mes systèmes a eu 16 IPv6 en même temps et une fois la limite atteinte, il ne prend plus de nouvelles adresses même si un nouveau RA se présente.
Je voudrais donc simplement que toutes les adresses deprecated soient supprimées immédiatement sans attendre le valid lifetime. Mais je n'arrive pas à trouver si une commande ou une conf existe ou s'il faut faire un script maison.
La solution ne serait-elle pas simplement de réduire le valid lifetime? Tu peux commencer par definir preferred lifetime à la meme valeur que valid lifetime, puis réduire progressivement?
Sinon, il y a la solution de faire de la translation de préfixe si ta connexion de backup (mobile) change de préfixe constament: utilises le préfixe délégué à la livebox (qui coupe, mais qui est stable) et NAT vers le préfixe actuellement alloué au routeur 4G.
Non, le souci c'est pas IPv6, c'est l'opérateur teubé qui change le préfixe à chaque coupure.
+1. Sur l'archi fixe, aucune excuse.
Sur le mobile, étant donné l'archi 3GPP et l'intérêt de réattacher un mobile à un PGW plus proche lorsque le mobile se déplace, c'est plus difficile.
-
Non, le souci c'est pas IPv6, c'est l'opérateur teubé qui change le préfixe à chaque coupure.
Bonjour
Je ne me permettrai pas de faire un jugement de valeur d'un collègue sur une infra réseau (que je ne connais pas) qui a fait des choix différents des miens pour des contraintes différentes des miennes.
Grâce à l'ARCEP il y a ici un magnifique tableau de comparaison des caractéristiques des différents opérateurs sur les IPv4 et préfix
https://www.arcep.fr/cartes-et-donnees/nos-publications-chiffrees/transition-ipv6/barometre-annuel-de-la-transition-vers-ipv6-en-france.html
Chacun choisi ce qu'il préfère, Orange est bien transparent sur ses choix. Et c'est cela le point important. Après, chacun est libre de ses choix et priorise ce qu'il veut dans les caractéristiques des différents opérateurs.
Je sais (étant vieux) que répondre quoi que ce soit c'est "nourrir le Troll" mais tant pis, là je fais. Cela sera mon dernier message sur ce point.
LeVieux
-
Je ne me permettrai pas de faire un jugement de valeur d'un collègue sur une infra réseau (que je ne connais pas) qui a fait des choix différents des miens pour des contraintes différentes des miennes.
Héhé, désolé si tu l'as pris comme ça, c'était pas l'objectif :) D'ailleurs il n'a pas dit que c'était Orange hein.
Mon point c'est juste de dire que le souci n'est pas le protocole mais son implémentation.
Si la moindre petite déco entraîne un changement de préfixe, c'est pas tenable en mobilité. Je n'ai pas ce comportement dans le TGV par exemple, et heureusement, sinon le service serait inutilisable.
Bon après y'a quand même de pires trolls sur ce forum que moi, non ? :)
Et heureusement qu'on peut se permettre de critiquer les choix d'architecture des confrères, c'est quand même ce genre d'échanges qui fait évoluer le milieu, si personne ne se remet en question et ne remet rien en question, alors rien n'avancerait.
-
Si la moindre petite déco entraîne un changement de préfixe, c'est pas tenable en mobilité. Je n'ai pas ce comportement dans le TGV par exemple, et heureusement, sinon le service serait inutilisable.
C'est régi par un timer il me semble : le signal peut temporairement être trop faible pour maintenir la connexion, mais aussi bien côté réseau que côté mobile, le PDP context est conservé pendant ~1 minute (dans mon expérience, mais ca peut être différent...). Si le mobile raccroche une antenne avant cette expiration, il n'y a pas de changement de préfixe (ni même de reconfiguration IP).
Par contre, le réseau peut décider de fermer le PDP context à tout moment. Donc si le mobile se raccroche à une antenne mais que le réseau désire qu'il change de préfixe (peu importe la raison), ca peut arriver aussi.
-
Et heureusement qu'on peut se permettre de critiquer les choix d'architecture des confrères, c'est quand même ce genre d'échanges qui fait évoluer le milieu, si personne ne se remet en question et ne remet rien en question, alors rien n'avancerait.
ça je suis d'accord, mais dans ce cas le "teubé" était de trop et fait passer de la critique constructive au Troll car il implique un jugement à priori sans connaitre les contraintes qui ont amené à ce choix.
LeVieux
-
Merci pour vos réponses.
Le routeur envoie bien un lifetime à 0 avant d’annoncer le nouveau préfixe. Mais les adresses restent jusqu'à la fin du valid llifetime, c'est bien comme ça que c'est censé marcher, non ? Le preferred lifetime est bien à 0 et donc la machine ne les utilise plus (mais essaie d'utiliser une ULA à la place, ce qui évidemment n'aboutit à rien).
Le problème ne se produit que lorsque il y a trop de coupures en 2h et que les préfixes n'ont pas le temps d’expirer, si pas de coupure ou très peu, tout va bien, ça s'efface au fur et à mesure.
Les préfixes sont en 7200 valid - 3600 pref.
EDIT : J'ai un doute @kgersen, tu parles du valid/pref du préfixe à 0 ou celui du routeur ? Car si c'est le préfixe, ça reste à 7200/3600 dans les 2 cas.
oui du prefix.
le RA a 2 roles: la route par défaut et le prefix (ce dernier étant optionnel).
Le lifetime a 0 du routeur (comme montrer dans ton screen) indique au réseau de ne plus utiliser ce routeur comme gateway / route par défaut. ce lifetime n'impacte pas le prefix annoncé.
Apres 7200 étant le mini pour le valid d'un prefix effectivement tu n'a pas trop le choix si c'est trop long.
-
ça je suis d'accord, mais dans ce cas le "teubé" était de trop et fait passer de la critique constructive au Troll car il implique un jugement à priori sans connaitre les contraintes qui ont amené à ce choix.
LeVieux
Exposer ici les contraintes d'Orange sur ce sujet, ferait avancer les choses ;)
-
Il faut aussi prendre en compte que quand Orange a fait ce choix, je ne pense pas qu'il considère comme "situation nominale" une livebox qui perd sa connexion toutes les 5 min car la ligne ADSL est pourri.
Le problème se produit dans un cas très précis et loin du cas d'utilisation normal.
-
Exposer ici les contraintes d'Orange sur ce sujet, ferait avancer les choses ;)
Rien de bien sorcier ni de caché, une réflexion sur ce qu'est le réseau Orange te donnerait les grandes lignes ci dessous :
- écouler un trafic en unité de dizaine de Tb/s
- avec une transfo majeur vers IPv6 Dual stack sans bloquer la marche vers IPv6 main et IPv4 secondary (en CGN, on y est pas encore, mais la route est posée sur la décennie suivante)
- avec un réseau en réorganisation continue (lente [ quoique ...] , mais continue)
- une volonté d'avoir une capacité a réorganiser les "arbres" client en les swappant d'OLT ou de BNG pour optimiser les flux
- garder le temps de transit minimal, un HOP c'est un HOP ...
- une volonté de garder le trafic non congestionné dans l'immense majorité des cas.
- une volonté de remonter un réseau poste black out EDF global en moins de 4h (de zéro à 13 millions dans mon cas)
- le tout sans que les clients s'en rendent compte ou presque
- dans un réseau à grosso modo entre 12 et 13 millions de clients
- en assurant un support client avec 99% de chance de retomber sur un service rendu au client par des manipulations simples.
- en passant d'un réseau 100% en propre (le cuivre) à un réseau grosso modo 50% acheté à des opérateurs Infra autres que Orange (Les RIP ou les autres opérateurs)
- dans un monde ou les fournisseur de matos et services découvrent aussi ce qu'est IPv6 à grande échelle (celle là n'est pas simple à gérer ...)
- en gérant la découverte par les fournisseurs de contenu de ce qu'est IPv6 ...
Je vous laisse réfléchir aux impacts d'un préfix en FIXE dans ce cadre
Je vous laisse à l'opposé réfléchir au impacts d'un préfix changeant à chaque reco
Après, dans cette liste, suivant l'opérateur que tu es ou veut être, y'a des options en plus ou en moins
Truc auquel on rajoute deux ou trois petites contraintes liées aux lois et demande de l'ARCEP ...
LeVieux
-
Attention, j'ai jamais critiqué le fait que le préfixe ne soit pas fixe, ça c'est normal. Seulement le fait qu'il change tellement rapidement que les hôtes tapent leur limite d'adresses temporaires.
Merci de ne pas me faire dire ce que je n'ai pas dit.
-
Merci de ne pas me faire dire ce que je n'ai pas dit.
Non, moi je ne te fais pas dire cela.
LeVieux
-
La solution ne serait-elle pas simplement de réduire le valid lifetime? Tu peux commencer par definir preferred lifetime à la meme valeur que valid lifetime, puis réduire progressivement?
Sinon, il y a la solution de faire de la translation de préfixe si ta connexion de backup (mobile) change de préfixe constament: utilises le préfixe délégué à la livebox (qui coupe, mais qui est stable) et NAT vers le préfixe actuellement alloué au routeur 4G.
Je suis déjà au mini sur le validlifetime (7200), après, est-ce que les hôtes peuvent décider de mettre moins, j'ai pas testé, mais ça impliquerait de modifier chaque hôte y compris windows... et je sais pas si c'est possible sur ce dernier.
Pour la translation de préfixe, il ne faut pas qu'il soit délégué ? J'avais souvenir qu'on ne pouvait pas faire de translation sur un préfixe déjà en cours d'utilisation (ce qui est assez logique). En tout cas c'est ce que je me rappelle sur pfsense quand j'ai voulu tester : je me faisais jeter si je prenais le préfixe côté WAN.
C'est régi par un timer il me semble : le signal peut temporairement être trop faible pour maintenir la connexion, mais aussi bien côté réseau que côté mobile, le PDP context est conservé pendant ~1 minute (dans mon expérience, mais ca peut être différent...). Si le mobile raccroche une antenne avant cette expiration, il n'y a pas de changement de préfixe (ni même de reconfiguration IP).
Par contre, le réseau peut décider de fermer le PDP context à tout moment. Donc si le mobile se raccroche à une antenne mais que le réseau désire qu'il change de préfixe (peu importe la raison), ca peut arriver aussi.
Expérience intéressante : sur mon tel, si je force le passage en 3G en décochant toutes les bandes LTE, le préfixe change (alors que ça se fait en ~5sec). Je me demande si ce n'est pas aussi lié au tel qui envoie un detach ?
La plupart de mes changements de préfixes ont lieu avec mon routeur si je change de bande manuellement. Je me demande s'il n'a pas un comportement similaire.
oui du prefix.
le RA a 2 roles: la route par défaut et le prefix (ce dernier étant optionnel).
Le lifetime a 0 du routeur (comme montrer dans ton screen) indique au réseau de ne plus utiliser ce routeur comme gateway / route par défaut. ce lifetime n'impacte pas le prefix annoncé.
Apres 7200 étant le mini pour le valid d'un prefix effectivement tu n'a pas trop le choix si c'est trop long.
Après vérification, il envoie aussi l'ancien préfixe avec valid et pref à 0. Lors du changement il envoie des dizaines de RA en 1-2sec avec et sans préfixe global. J'avais pas regardé les bons paquets...
-
Expérience intéressante : sur mon tel, si je force le passage en 3G en décochant toutes les bandes LTE, le préfixe change (alors que ça se fait en ~5sec). Je me demande si ce n'est pas aussi lié au tel qui envoie un detach ?
La plupart de mes changements de préfixes ont lieu avec mon routeur si je change de bande manuellement. Je me demande s'il n'a pas un comportement similaire.
Si je passe en mode avion et en ressort, j'obtient aussi un préfixe différent (et je peux observer avec NetworkTools de HE que les interfaces cellulaires sont déconfigurées).
Je pense que quand tu changes les bandes disponibles, tu reconf le modem et il fait probablement un detach/reattach, en effet.
-
Je viens de tester avec orange, comportement identique : le préfixe change au passage en 3G ou mode avion.
-
Après vérification, il envoie aussi l'ancien préfixe avec valid et pref à 0. Lors du changement il envoie des dizaines de RA en 1-2sec avec et sans préfixe global. J'avais pas regardé les bons paquets...
j'imagine que les RA étant non acquittés , sur une réseau non fiable comme du wifi il est de bonne pratique de spammer plusieurs fois histoire qu'une perte de paquet ne perdre pas l'info ;)
pour le problème initiale, il manque une option de config pour soit ignorer "la protection des 2 heures" soit whitelister une interface par exemple.
Peut-être en fouillant dans les sysctl de Linux y'a quelque chose la dessus (j'en doute). (La norme ne définie que SEND (rfc3971) mais je n'ai pas regardé récemment ses mises en oeuvre).
c'est peut-etre un truc a proposer pour mettre dans le Linux kernel :)