RE DHCPv6 Confirm in DOCSIS networks

[Jean-Francois.TremblayING at videotron.com]

Hello Tore. 

> I understood from my provider that the likely cause was that their Cisco
> CNR DHCPv6 server did not support DHCPv6 Confirm

Not the CNR's fault, as Ole's mentioned. The CMTS code they use probably 
does not relay the Confirm to the DHCPv6 server. It's fixed in some 
later versions of one CMTS manufacturer we tested. 

> This strikes me as rather strange - as far as I can tell, the DHCPv6
> client has no way of determining if the Ethernet interface is running on
> is connected to a DOCSIS modem or something else, so I don't see how it
> could possibly selectively disable the use of Confirm in the case of 
DOCSIS.
> 
> Does anyone have more information on why DHCPv6 Confirm wouldn't be
> expected and supported in DOCSIS networks? (Does it work in Comcast's
> network?)

This exact topic was brought to the dhcp wg list this winter
(http://www.ietf.org/mail-archive/web/dhcwg/current/msg12404.html). 
If the Confirm is sent and answered, a host could continue working 
in theory. However a home router won't get any confirmation its IA_PD 
is still valid. 

The choices here are either to avoid sending or answering Confirms
or to add mechanisms in the relay (CMTS) to check if there's an 
IA_PD through a Lease Query each time a Confirm is seen. 

The only way to always have it working is to go with the latter. 
However I am aware that some client implementations now avoid sending 
any Confirms and instead restart their state machine with a Solicit 
when the link flaps. It's a bit more load/work, but the results are
more deterministic. This is preferable IMO. 

/JF