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

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

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?

- Bernie

On Sep 16, 2012, at 12:17 PM, "Hemant Singh (shemant)" <[e-mail]> wrote:

> Bernie,
> 
> Here is what I prefer for text for section 4.4 of the document.  All other text in the current section 4.4 is redundant with RFC 3315.
> 
>   The Confirm message, as described in [RFC3315], is specific to
>   address assignment.  Note a server processing a Confirm message
>   that includes only IA_NAs does not have to look up any client
>   bindings. This document extends the Confirm to include other 
>   IA option types.  It is desirable other IA option 
>   types do not enforce the server to look up any client bindings 
>   to respond to a Confirm.  Another IA option type is the IA_PD. 
>   The server uses configured prefixes to determine if a prefix in 
>   the IA_PD option is on-link to respond to a Confirm.
> 
> Another issue I'd like to bring up for the Confirm section of this document.  I realize the document only supports the case of one server replying to both the IA_NA and the IA_PD.  However, after a client has completed DHCPv6 for both the IA_NA and the IA_PD, some configuration on the server changes.  Later the client issues a Confirm and the server configuration change causes one IA type to fail the on-link check.  If the Status code option in the Reply is global, the Reply has a failed on-link code and the client moves to Solicit processing and the Solicits may continue indefinitely.  I recommend using the Status code option per IA option type.  Then for an IA option type not on-link status, the client can now use Information-request rather than moving to a Solicit transaction.  Thus more text changes to RFC 3315 are required.
> 
> Hemant
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Hemant Singh (shemant)
> Sent: Friday, September 14, 2012 9:09 PM
> To: Ted Lemon; Bernie Volz (volz)
> Cc: dhc WG; Ole Troan (otroan)
> Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00
> 
> Ted/Bernie/Ole,
> 
> Humble apologies I was buried with other priorities and did not check my DHC WG email folder in a while. I actually replied to the xlat document in v6ops during my 10 days of PTO up till the Labor Day.  Bernie kindly reminded me this week of this document.  Most of my comments have been addressed.  Some pending are included below.
> 
> Why was the CONFIRM message deliberately specified by RFC 3633 as not supported for the IA_PD?  
> 
> It would be good to reply to this question.  Otherwise the IESG is likely to ask the same question and the answer to such a question may uncover issues for us.  
> 
> For one, it is easy for a server to respond to a CONFIRM to an IA_MA by just matching the IPv6 address configured on the machine the server is running on.  I am always reminded by some authors of RFC 3315 that the server distinctly does not consult its client bindings to respond to a CONFIRM for an IA_NA.  The server just relies on the machine IPv6 configuration to compute a status of on-link or not-on-link.  Thus why it is not a sea-change to support the CONFIRM for the IA_PD option and we may need to step gingerly?  If the server has to respond to a CONFIRM for an IA_PD, the server now consults with its bindings (I think Bernie alluded to in his reply to this thread) which the server did not do before for the IA_NA.  Searching thru bindings has delay implications and additional server computations.  Or as I had already said in my earlier reply that the server checks what prefixes are configured on the server to determine on-link status.  However checking prefixes for IA_PD 
> at a server has to exclude prefixes that are used for allocation of IA_NA.  So now the server maintains two types of prefixes.  
> 
> Thus I will try and propose some text over the weekend that IA_PD support in CONFIRM can't suffice with network configuration.  Some other data in the server needs checking and we should try and be little specific about the data.  Just saying something like "the sever checks network configuration" doesn't cut it for the IA_PD.  
> 
> Let me see what I can do over this weekend and propose some text as to how the server checks for on-link or not for the IA_PD to respond to a CONFIRM.  I will also catch up with other emails on this document and reply, if necessary.
> 
> Regards,
> 
> Hemant
>