RFC7084 compliant DHCPv6 behavior about bngblaster HOT 4 CLOSED

Most relevant for this use case is TR-177 but I will do some investigation here.
https://www.broadband-forum.org/download/TR-177.pdf

from bngblaster.

https://datatracker.ietf.org/doc/html/rfc4861#section-4.2 also says that either should be accepted:

"If the M flag is set, the O flag is redundant and can be ignored because DHCPv6 will return all available configuration information."

Or as said a slightly different way at https://blog.ipspace.net/2012/11/ipv6-router-advertisements-deep-dive.html

"The O flag is meaningless if the M flag is set, as the O flag is basically a subset of the M flag (broken OS stack might require both though)".

FWIW, TR-177 just seems to talk about the O-flag:

"The BNG generates (according to RFC 4861 [12]) an IPv6 MC RA message to the FF02::1 “All link-local nodes” MC group. The BNG includes the /64 prefix of the access line in the Prefix Information Option (PIO) of the RA and sets the ‘A’-flag of this PIO to ‘True’ in order to advise the RG or host to use the included PIO for the SLAAC of its WAN GUA. Besides that the ‘Is-router’ flag and the O-flags inside the RA are also set to ‘True’ in order to signal that the BNG is the Default Router and that more information can be provided by DHCPv6. This RA message is encapsulated in a newly created IPv6 datagram with the Line Identification Option (LIO) and is sent to the AN, according to RFC 6788 [25]"

from bngblaster.

Fixed in latest dev branch.

from bngblaster.

Fixed in 0.7.9!

from bngblaster.