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

["Hemant Singh (shemant)" <[e-mail]>]

Bernie & Ole,

Sorry for the delay.  Please see in line below.  Also, let's talk sometime next week at work and we can resolve the issues offline and then let the mailer know.

-----Original Message-----
From: Bernie Volz (volz) 
Sent: Sunday, September 16, 2012 8:27 PM
To: Hemant Singh (shemant)
Cc: Ted Lemon; dhc WG; Ole Troan (otroan)
Subject: Re: WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00

>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. 

That's one server.  We could use text that has generic requirements for all servers.  I wrote a bunch of text including text that says client bindings should not be looked up.  I also said most of the text in the Confirm section of your document is redundant with RFC 3315.  Thus it makes sense to retain most of the text I proposed.  I think the text you say is false is this.

"The server uses configured prefixes to determine if a prefix in the IA_PD option is on-link to respond to a Confirm."

>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.

Hmm, does DHCPv6 assign a link-local address to a client that a client will issue a Confirm for a link-local address?  I am also replying to Ole in this email.  Ole said 

"(the reason we did what we did in 3633 with regards to Confirm, was because of the text around "Onlink"." 

It makes sense that OnLink is defined in some document.  Both RFC 3315 and RFC 4861 have identical definition for "link".  This definition says nodes on the link can communicate below the IP layer.  So how is a globally routable IPv6 address in an IA_NA or a prefix in the IA_PD determined to be OnLink when both entities communicate at the IP layer?  I know you have given details on how does your server determines OnLink.  But those are details and internal constructs of one server.  We need an example for how do all servers determine what is OnLink for the IA_PD prefix.
  
>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.

Looking up a link matching a prefix configuration does not work for all cases.  The client moves and another link on the server can serve the same prefix.  So now the server has to look up a collection of prefixes.  How are prefixes collected?  Based on what metric? 

>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?

If you don't have a good way to return separate status codes for prefix vs. address, then I doubt if the sever has a good way to determine if each of the prefix and address is NotOnLink?  Why would the Solicit not continue forever.  Then network has only one server.  The server has removed one IA type and the client 's Solicit will not be responded by the server any more.  Thus if Reply received to a Confirm has one IA type as NotOnLink, the client switches to the Information-Request with that IA type. 

Thanks,

Hemant