Le support de PXE sur IPv6 est disponible via odhcpd mais le fonctionnement ne me semble pas clair, est-ce que certaines options sont communes avec dnsmasq (typiquement le dossier contenant les fichiers d'amorce) ?

Il vaut mieux suivre les recommandations de l'opérateur réseau.

Oui, mais jusqu'à une certaine limite... à part si on le fait pour le kif, aucun intérêt selon moi à pousser les gens à avoir des scripts de rotation/régénération de chaîne d'auth sur leur routeur.
On ajoute de la complexité (et donc un risque de pannes) pour un gain virtuellement nul, et pour ceux qui sont moins à l'aise, c'est des étapes en plus, qu'il faut configurer en SSH, etc.

Plutôt d'accord avec Julien : Si tu commences à compter l'AS-SET pour AS62000 (AS-SET AS-NETRIX), par exemple, tu va te retrouver avec plusieurs centaines de milliers d'IP, liés à nos sous clients, alors que la vaste majorité ne sont pas annoncés via chez nous.

Le mieux reste de se baser uniquement sur les blocs liés à l'AS directement, et là deux solutions :
A/ Se baser sur ce que les IRR autorisent (via bgpq4 par exemple), mais c'est "théorique", ça ne veut pas dire que les blocs sont réellement annoncés/utilisés en ce moment
B/ Se baser sur ce qu'il y a d'annoncé dans la DFZ, par exemple via BGPtools ou HE (https://bgp.tools/as/62000)

Oui effectivement, il semble plus intéressant d'afficher le nb d'IPv4 annoncé par le peer (soit l'AS + ses clients).

Il y a une commande simple pour l'avoir depuis un Linux ?

Non car ca du coup tu auras ceux qui mettent dans leur cone tout et n'importe qui. Du coup sur le LG de l'IX, soit ma commande qui est valable pour dire ce qu'un réseau à en IP.

Désolé mais moi je trouve que ca veut rien dire sinon de dire qu'un AS c'est X IP si ce sont ses clients, ils peuvent prepend a mort et donc 0 traf, ou meme peut s'enlever après....

@zof @simon :

Il vaut mieux suivre les recommandations de l'opérateur réseau.

@nando11 :

L'application d'un correctif à odhcpd a abouti sur une cascade de modifications : DUID global + IAID. Pour en savoir plus, lire le commentaire de Noltari dans le ticket « 25.12.0-rc3 breaks static DHCP from network ».

dhcp.sh

[ -z "$clientid" ] && clientid="$(proto_dhcp_get_default_clientid "$iface")"
[ -n "$clientid" ] && clientid="-x 0x3d:${clientid//:/}"

Commit e24ac1c (odhcp6c)

diff --git a/src/dhcpv6.c b/src/dhcpv6.c
index fa0c2a1..2075006 100644
--- a/src/dhcpv6.c
+++ b/src/dhcpv6.c
@@ -479,9 +479,11 @@ static void dhcpv6_send(enum dhcpv6_msg type, uint8_t trid[3], uint32_t ecs)
        ia_na_entries /= sizeof(*e);
 
        struct dhcpv6_ia_hdr hdr_ia_na = {
-               htons(DHCPV6_OPT_IA_NA),
-               htons(sizeof(hdr_ia_na) - 4),
-               htonl(1), 0, 0
+               .type = htons(DHCPV6_OPT_IA_NA),
+               .len = htons(sizeof(hdr_ia_na) - 4),
+               .iaid = htonl(ifindex),
+               .t1 = 0,
+               .t2 = 0,
        };
 
        struct dhcpv6_ia_addr pa[ia_na_entries];
@@ -1156,7 +1158,7 @@ static int dhcpv6_handle_reply(enum dhcpv6_msg orig, _unused const int rc,
                                        continue;
 
                                // Test ID
-                               if (ia_hdr->iaid != htonl(1) && otype == DHCPV6_OPT_IA_NA)
+                               if (ia_hdr->iaid != htonl(ifindex) && otype == DHCPV6_OPT_IA_NA)
                                        continue;
 
                                uint16_t code = DHCPV6_Success;


En résumé, il n'y a que le changement de DUID qui est potentiellement impactant. Dans la requête d'intégration, on voit que la modif. correspond à IA_NA et pas à IA_PD.

Édit : D'ailleurs c'est assez curieux que IA_PD ne soit pas traité. Un oubli ?