Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00

["Bernie Volz (volz)" <[e-mail]>]

Hemant:

Where do you stand on this? Is the Confirm still an issue for you? Is there something to add to the draft to help clarify things?

- Bernie

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Ole Trøan
Sent: Monday, September 17, 2012 4:03 AM
To: Bernie Volz (volz)
Cc: dhc WG; Ted Lemon
Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00

Bernie,

> The server I work on does not look up bindings for Confirming IAPREFIX (the server has allowed Confirm on prefixes since day one) so this text is false and is not required. The server does the same processing it does for addresses. It looks up the link and prefix configuration and if the delegated prefix sent by the client (or address sent by the client) is contained by a configured prefix the client is told success. If it can't tell (this is mostly the case for addresses that are link-local but also in cases where the clients "location" can not be determined from one of the addresses or prefixes provided by the client) it doesn't respond. Otherwise the client is told not-on-link.
> 
> Confirm never says a particular address or prefix is leased to the client. It just says whether the client has clearly moved or not (no response means the server can't determine).
> 
> So, I do not agree with this text change at all.
> 
> Regarding the second issue ... If the configuration has changed to remove prefix delegation or addresses, but not the other, and the Confirm returns Not-On-Link, client would move back to Solicit but why would Solicits continue forever? Are you thinking a client would implement some, but not all changes? I would think that is wrong - this is a package of changes the client and server need to implement. So, the other changes would prevent the continous Solicits? We have no good way to return separate status codes for prefix vs address and I don't see this as needed per what I just wrote?
> 
> Note that likely the client will get back the same address or prefix when it Solicits, just won't get the other that is no longer configured.
> 
> Perhaps Ole has a different view or there is something I am missing here?

I have the same view as well.

(the reason we did what we did in 3633 with regards to Confirm, was because of the text around "Onlink". in hindsight we've realised that having different behaviour per IA was a bad idea, and Bernie came up with a simple fix for how to use Confirm for IA_PD also.)

cheers,
Ole