J'avais effectivement lu la trace un peu rapidement, la source des paquets est l'adresse publique côté box, pas l'adresse en 192.168/16. Donc ton filtre initial ne fonctionnait pas.

C'est bien ça.

Je ne te suis pas ...
Pour moi, la box est elle-même serveur DHCP sur la plage que tu configures par l'interface, en IPv4.
Elle n'est pas relais DHCP et les paquets DHCP du LAN n'ont pas à sortir.
Les paquets APIPA quels qu'ils soient n'ont pas à sortir du LAN non plus.
Je reste sur l'hypothèse que j'évoquais hier : Ne pourrait-il pas s'agir simplement de box qui ne sont pas configurées côté serveur DHCP (ou ACL Covage) et qui finissent pas s'autoconfigurer en APIPA (sur leur interface WAN)?

Par machine ou appareil Covage, je fais référence à la passerelle/relais chez Covage qui collecte les clients K-Net, ce sur quoi tous les clients K-Net du GPON (14 et 91) sont raccordés, et qui :
– laisse passer les paquets broadcast et multicast et l'unicast APIPA de l'appareil Siemens… depuis et vers tous les clients : comportement de proxy ou switch,
– fait office de relais DHCP pour le compte de K-Net (les clients DHCP WAN v4 ou v6 des clients ne se connectent pas directement au serveur DHCP de K-Net, mais au relais DHCP de Covage qui ajoute ses ACL et modifie la dure du bail à 5 minutes [le serveur K-Net demande 24h je crois]) ; bien entendu le relais Covage communique avec le serveur K-Net (cf. protocole DHCP Relay https://www.it-connect.fr/chapitres/quest-ce-quun-agent-relais-dhcp/).
– fait office de passerelle de routage et ne laisse (heureusement) pas passer les paquets unicast entre les clients (à part ce Siemens…).

En ce qui concerne la K-Box, on est bien d'accord :
– elle possède un serveur DHCP LAN pour la configuration IP des appareils sur le LAN. Ce n'est bien sûr pas un relais et ça doit rester uniquement sur le LAN. D'ailleurs, même avec les fuites, je crois qu'on ne voit pas passer de trames DHCP du LAN des clients impactés… Donc probablement un filtrage Covage de que les clients émettent sur les ports serveur DHCPv4 et v6, ce qui évite de plus gros problèmes encore dans le GPON avec plusieurs serveurs DHCP qui seraient en compétition…
– les paquets d'adresses APIPA de la K-Box (quelle que soit leur raison d'être) n'ont pas à être sur le GPON (donc envoyés côté WAN par les K-Box).

Sur l'origine des adresses APIPA, c'est le plus logiquement (comme tu le suppose) :
– soit une configuration automatique APIPA de l'interface côté LAN qui fuit sur le GPON (donc on voit ces paquets à cause du bogue de la fuite déjà mentionné),
– soit une configuration automatique APIPA de l'interface côté WAN qui du coup ne fuit pas, mais ce serait là une grossière erreur de conception…

Maintenant, pourquoi Covage ne bloque-t'il pas (entre autres) les adresses APIPA dans le GPON ? Car non seulement les paquets APIPA broadcast et multicast sont transmis entre les clients du GPON, mais également certains paquets unicast (paquets Siemens…)
Pourquoi Covage relais-t'il les paquets broadcast et multicast entre tous les clients d'un même GPON ? Ils pourrait déjà restreindre aux seuls paquets nécessaires (DHCP), et par la suite cloisonner les clients (je ne vois vraiment pas ce qui pourrait bloquer cela techniquement, mais sans un datagram de l'infra de collecte Covage, on ne peut que discuter dans le vide).

C'est hors de mon champ de compétences.
Je ne suis d'ailleurs pas sûr que le réseau de mon OI (Covage canal historique) soit en GPON (plutôt en P2P).

Peut-être une différence qui explique pourquoi tu ne rencontres pas de problèmes avec ta K-Box ?
Peut-être que tu as des fuites, mais que la partie Covage historique ne les laisse pas passer, donc au final tout va bien. Si tu as le temps un jour, je serais curieux de savoir ce que tu entends dans ta boucle… Peut-être est-elle silencieuse…

Mon GPON est tout le 14 et une partie du 91 (Tutor historique), et force est de constater que les problèmes de fuite (LAN/WAN) et le bogue de boucle DHCPv6 ne semblent se présenter (ou être visibles) que sur mon GPON et peut-être quelques autres, mais ce n'est apparemment pas présent dans toutes les collectes Covage de France, et à priori pas du tout chez les autres OI… Donc je suspecte qu'il y a probablement plus de K-Box défaillantes qu'on ne le pense, mais selon les boucles de collectes dans lesquelles elles se trouvent, ces défaillances sont invisibles et sans conséquences (pour le client et ses voisins de boucle…)

Ca semble aussi confirmer que certaines boucles sont peut-être mieux conçues (meilleur cloisonnement des clients) que d'autres…

Autre indice… tu n'as jamais eu IPv6 fonctionnel… Alors que moi si. Donc nous sommes sur deux boucles bien différentes (Covage historique et Tutor historique).

Sur ta suggestion :J'ai un vieux PC sous fedora branché en Ethernet à la box (tout le reste est en WIFI chez moi), je tenterai un "port mirroring" un soir pour chercher des paquets suspects côté WAN.

Premier tentative de port mirroring du port WAN de la K-Box vers le port Ethernet où se trouve le PC sur lequel je lance tcpdump.
Je ne vois pas le trafic WAN 
La configuration modifiée apparaît bien dans le panel de la box, que j'ai redémarrée pour être sûr que les modifications avaient été appliquées (alors que l'enregistrement de la modification de configuration provoque déjà un reboot de la box).

Tu ne vois rien du tout ?
L'autre solution est de mettre le PC directement sur l'ONT, et de cloner la MAC de la K-Box.

Rien non plus chez moi (Covage74) sur le WAN sauf quand j'avais merdé la config de mon trunck (VLAN marqué) entre étage. A l'époque VincentO me l'avait signalé et je m'était un peu demandé comment il l'avait repéré (maintenant je sais comment!).
J'ai un switch manageable entre ONT et k-box, avec lequel je peux faire du port-mirroring vers mon LAN.
Absolument aucun paquet qui ne m'est pas destiné.
Et tous les paquets que je vois passer sont bien issus de la MAC de la passerelle K-net (IP.254).

Je n'avais pas pris l'option de tcpdump pour garder les entêtes Ethernet, je referai l'expérience une autre fois pour confirmer l'origine des paquets que je reçois.

Je triche en utilisant https://www.wireshark.org/ qui affiche tout le contenu des paquets facilement. 

C'est intéressant…

Sur 1 seconde d'écoute, pour tout ce qui ne me concerne pas en broadcast et multicast, j'obtiens une dizaine de packets :
<<< couic >>>
Ce n'est que sur une seule seconde. Durant cette seconde particulière, je n'ai capturé aucun paquet BOOTP (DHCPv4) ou DHCPv6, mais il sont aussi très fréquents (les négociations normales DHCPv4 et v6 des clients).

voir ci-dessous (il trainait encore un mdns issu de mon PC) :
$ egrep -v "mon-ip-publique|mdns" trace-retravaillee.txt
08:05:02.386997 IP 10.0.0.113 > 224.0.0.1: igmp query v2
08:05:29.719343 IP6 fe80::7386:746f:4f84:4cb0 > ff02::2: ICMP6, router solicitation, length 8
08:05:32.210504 IP 10.0.0.110 > 224.0.0.1: igmp query v2
08:05:38.017117 IP 10.0.0.11 > 224.0.0.1: igmp query v2 [max resp time 200]

C'est tout ce que j'ai vu ce matin. Je n'avais pas de filtre tcpdump.

Il semble donc qu'entre mon GPON d'un côté, et ceux de Steph ou pju91, il y ait bien une différence de conception, puisqu'ils ne voient aucun de ce type de paquets.
Covage 91 historique et Covage 74 semblent donc avoir une réelle étanchéité de tous les paquets entre les clients, y compris pour le broadcast et multicast.

Ca semble donc confirmer mon hypothèse que les problèmes rencontrés par les clients K-Net sur la boucle Tutor historique 14 et 91 proviennent de la conjonction de deux choses :
1- les différents problèmes au niveau de certaines K-Box (fuite, spam DHCPv6…)
2- la porosité dans le GPON entre les clients aux paquets broadcast, multicast et certains unicast.

Bien entendu, les problèmes de fuite des K-Box doivent absolument être résolu.
Par ailleurs, si Covage 14 et 91 (réseau Tutor historique) pouvait améliorer l'étanchéité entre clients, ça serait bien aussi…

Clairement, l'ingéniérie des réseaux Tutor et Covage (historique) n'est pas la même.
Comme en plus, je bénéficie d'un raccordement à un PM récent (ouverture commerciale fin 2018), ce n'est pas encore la jungle et je ne subis pas de déconnexions intempestives comme sur des réseaux plus anciens où le "churn" et les nouveaux raccordements dégradent les PBO et PM, donc mon accès Internet est très stable.

Tu as cependant un ICMPv6… il vient de ton PC ? Ou du relais Covage ? Si non, il n'y aurait donc pas une étanchéité totale… Peut-être que tu ne verrais que certains paquets seulement sur ton PM ?

Mon PC s'autoconfigure certes en IPV6 (avec une adresse link local). Je ne l'ai pas regardée durant mon test, mais un calculateur d'adresse IPv6 link local (par rapport à la MAC de la K-Box ou à l'adresse physique) me donne d'autres adresses que celle vue dans la trace.
Toutefois, comme c'est du multicast pour "tous les routeurs du réseau local", ça ne me choque pas de trouver un tel paquet.
Je referai des tests sur une plus longue période (et en gardant les entêtes Ethernet).