Je viens de tester en spécifiant les options à la main :
odhcp6c -V 0000040e0005736167656d  -u FSVDSL_livebox.Internet.softathome.livebox4 nas0

Et cette fois ça fonctionne ! Par contre comment envoyer l'option 11 ? Je ne vois aucun argument qui corresponde...

EDIT : Bon va falloir que j'upgrade de toute évidence 
https://lafibre.info/remplacer-livebox/remplacement-de-la-livebox-par-un-routeur-lede-fork-dopenwrt/msg531290/#msg531290

Pour ipv6, c'est un peu plus compliqué : le client DHCPv6 (odhcp6c) de LEDE 17.04.1 ne supporte pas les options arbitraires mais il a été mis à jour dans les versions de développement (https://git.openwrt.org/?p=project/odhcp6c.git;a=commit;h=510aaf6d528210c5e8a6159f9b80b32615e88c5f). Sur une install 17.04.1 à jour, on peut l'installer assez facilement de la facon suivante:

@Renaud07, j'ai eu le meme souci il me semble en suivant le tuto de fatpat mais je ne me souvient plus très bien comment je l'ai réglé, de mémoire c'était du coté de la config dhcp, je crois que j'ai forcé les dns du lan.
Je le reinstalle et je te dis.

Edit:
Voilà il me semble qu'en mettant ça dans /etc/config/dhcp  le probleme s'est résolu tout seul.
config dhcp 'lan'
option interface 'lan'
option start '251'
option leasetime '21600s'
option dhcpv6 'server'
option ra 'server'
option ra_management '0'
option ra_mininterval '200'
option ra_maxinterval '600'
option ra_lifetime '1800'
option ra_hoplimit '64'
option force '1'
option ignore '0'
option limit '2'
        list dhcp_option '6,81.253.149.10,80.10.246.3'
        list dhcp_option '15,orange.fr'Après tu relances dnsmasq sur le routeur et sur le PC un ipconfig /renew

je ne sais pas si c'est en faisant ca ou si c'est une coincidence et que le probleme s'est finalament réglé tout seul, mais j'avais comme toi des soucis sur pas mal de sites, pour certains ca marchait pour d'autre pas du tout, et en forcant un dns autre que celui du routeur ca a fonctionné.

Résumé de cette journée :

J'ai réupgrade le BTHH5 des parents en 18.06 : ça fonctionne pour le moment et j'ai enfin de l'ipv6 natif ! A voir sur la durée, si ça plante ou pas. Voir si je bascule le mien aussi.

Enfin, ça à l'air de mal partir car j'ai eu un beau bug un peu avant : La première fois que j'ai testé, si j'obtenais bien une V6, ainsi que les appareils, sur un site de test ça me disait que j'en avais pas. J'ai donc remonté temporairement mon tunnel HE, car je n'avais plus le temps il fallait que je parte.

De retour à la maison, je continue mes tests via mon VPN. Tout va bien pendant ~1h, et là je me décide à remonter la MTU du tunnel (qui me sert à avoir une ip fixe) puisque je ne suis plus limité par le PPPoE. Et bizarrement quelques minutes après avoir fait la modif, ça commence à déconner : impossible d'accéder à l'interface du routeur ou mon proxmox (temps d'attente dépassé) Seuls les ping passent et encore très difficilement (ça fluctue bcp avec parfois des retours à 1sec !) bref... la cata.

Je bascule la connexion en V4 (vu que maintenant c'est censé être en ip fixe) : tout redevient normal et j'ai même gagné en vitesse (passer de 100ms avec le tunnel à 40ms en direct ça change beaucoup, on dirait que j'ai doublé mon débit alors que pas du tout). Depuis ça n'a pas replanté, mais je surveille ça de près.

Un peu plus tard je me suis remis à le recherche du pourquoi je n'avais pas de V6 sur les machines et j'ai finalement trouvé assez rapidement que je m'étais gouré sur 2-3 règles de pare-feu (les zones n'étaient pas les bonnes noramment) et une fois corrigé, magie ça marche 

Pour la blague, petite capture sur windows XP 

Salut,

Le DHCP NAK sert à 2 choses : signaler la fin du bail ou des paramètres invalides envoyés par le client.

J'ai attendu la fin de mon bail cette nuit voir ce qu'il se passait chez moi : j'ai un simple renew sans  DHCP NAK. Après ça dépend peut-être de la version d'OWRT (par ex je n'ai pas "sending renew to XX..." mais juste "sending renew") :
Wed Mar 17 04:10:36 2021 daemon.notice netifd: WAN_DHCP (2620): udhcpc: sending renew
As-tu ajouté la Qos avec le script ? Car en ADSL (si c'est bien ton cas), ce n'est pas nécessaire.

Bon j'ai continué mes investigations à coup de tcpdump. Normalement j'ai masqué les données sensibles.

L'envoi du renew :


16:29:56.151634 Out xx:xx:xx:xx:xx:xx ethertype 802.1Q (0x8100), length 407: vlan 832, p 0, ethertype IPv4, (tos 0x0, ttl 64, id 13091, offset 0, flags [DF], proto UDP (17), length 387)
    XXX.XXX.XXX.XXX.68 > YYY.YYY.YYY.YYY.67: BOOTP/DHCP, Request from xx:xx:xx:xx:xx:xx, length 359, xid 0x372a7b0e, Flags [none]
          Client-IP XXX.XXX.XXX.XXX
          Client-Ethernet-Address xx:xx:xx:xx:xx:xx
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message Option 53, length 1: Request
            MSZ Option 57, length 2: 576
            Parameter-Request Option 55, length 12:
              Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname
              Domain-Name, BR, NTP, Lease-Time
              RN, RB, AUTH, Classless-Static-Route
            Vendor-Class Option 60, length 5: "sagem"
            Hostname Option 12, length 7: "routeur"
            User-Class Option 77, length 44:
              instance#1: "FSVDSL_livebox.Internet.softathome.Livebox4", length 43
            AUTH Option 90, length 33: 0.0.0.0.0.0.0.0.0.0.0.a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p.q.r.s.t.u.v
16:29:56.192316   P a0:f3:e4:51:a7:95 ethertype 802.1Q (0x8100), length 323: vlan 832, p 0, ethertype IPv4, (tos 0xc0, ttl 64, id 15380, offset 0, flags [none], proto UDP (17), length 303)
    YYY.YYY.YYY.YYY.67 > XXX.XXX.XXX.XXX.68: BOOTP/DHCP, Reply, length 275, xid 0x372a7b0e, Flags [none]
          Client-Ethernet-Address xx:xx:xx:xx:xx:xx
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message Option 53, length 1: NACK
            Server-ID Option 54, length 4: YYY.YYY.YYY.YYY
            MSG Option 56, length 1: " "


On voit donc que le serveur DHCP répond NACK, pas gentil.
Juste après le discover/offer qui se passe bien et le deuxième request :


16:29:59.434357 Out xx:xx:xx:xx:xx:xx ethertype 802.1Q (0x8100), length 419: vlan 832, p 6, ethertype IPv4, (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 399)
    0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from xx:xx:xx:xx:xx:xx, length 371, xid 0x50eefa22, Flags [Broadcast]
          Client-Ethernet-Address xx:xx:xx:xx:xx:xx
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message Option 53, length 1: Request
            Requested-IP Option 50, length 4: XXX.XXX.XXX.XXX
            Server-ID Option 54, length 4: YYY.YYY.YYY.YYY
            MSZ Option 57, length 2: 576
            Parameter-Request Option 55, length 12:
              Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname
              Domain-Name, BR, NTP, Lease-Time
              RN, RB, AUTH, Classless-Static-Route
            Vendor-Class Option 60, length 5: "sagem"
            Hostname Option 12, length 7: "routeur"
            User-Class Option 77, length 44:
              instance#1: "FSVDSL_livebox.Internet.softathome.Livebox4", length 43
            AUTH Option 90, length 33: 0.0.0.0.0.0.0.0.0.0.0.a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p.q.r.s.t.u.v
16:29:59.491195   B a0:f3:e4:51:a7:95 ethertype 802.1Q (0x8100), length 483: vlan 832, p 6, ethertype IPv4, (tos 0xc0, ttl 64, id 15516, offset 0, flags [none], proto UDP (17), length 463)
    ZZZ.ZZZ.ZZZ.ZZZ.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 435, xid 0x50eefa22, Flags [Broadcast]
          Your-IP XXX.XXX.XXX.XXX
          Server-IP YYY.YYY.YYY.YYY
          Gateway-IP AAA.AAA.AAA.AAA
          Client-Ethernet-Address xx:xx:xx:xx:xx:xx
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message Option 53, length 1: ACK
            Server-ID Option 54, length 4: YYY.YYY.YYY.YYY
            Subnet-Mask Option 1, length 4: 255.255.248.0
            Default-Gateway Option 3, length 4: ZZZ.ZZZ.ZZZ.ZZZ
            Lease-Time Option 51, length 4: 259200
           [....]


En comparant les 2 request on voit que la différence est que la première est fait à partir de l'IP et non pas en broadcast mais à priori c'est normal.
La deuxième est que dans la première les 2 options 50 et 54 ne sont pas envoyés (mais en contrepartie Client-IP est envoyé au début).

Est-ce que ça peut expliquer le NACK ?