Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-06.txt

[Cong Liu <[e-mail]>]

Hi,

I have a question on section 4:
   "Proposed solution: the client should keep *a single session* with the
   server and include the missing options on subsequent messages
   (Request, Renew, and Rebind) to the server.

My understanding is that it implicitly objects to "create separate DHCP
sessions for each IA option type" in the previous paragraph.

If there are two servers: server_A only replies IA_NA and server_P only
replies IA_PD. The client sends Solicit message requesting both IA_NA and
IA_PD, and receives Advertise messages from both servers. Will the client
only keep a single session with just one of the servers, or two sessions
with both servers? For the former case, the client will unlikely get both
IA_NA and IA_PD although it continue requesting both IA_NA and IA_PD
in subsequent
messages.

If it is the latter case, what would be in the client's IA_NA in subsequent
Request, Renew, and Rebind messages to the server_P? Does the IA_NA to
server_P contains the IA_NA address from server_A's Advertise (that's what
the client gets), or no address (that's what server_P has replied) ?

Best Regards,
Cong



2014-07-01 0:55 GMT+08:00 Bernie Volz (volz) <[e-mail]>:

> Hi:
>
> A new version of this document has been posted. Sorry for the long delay
> but there were some significant changes to make and thanks to Marcin for
> joining the authors to make some of those changes.
>
> The major differences are:
> 1. Sections 4.1 and 4.2 (Advertise Message and Placement of Status Code)
> were swapped. The reason for this is because we decided to use the Reply
> formatting for the status codes in Advertise too. It turns out that there
> are server implementations that did already use this formatting and there
> have been no reported issues. So, client implementations must be handling
> this acceptable. This is a better long term solution since it doesn't
> special case the IA_NA/IA_TA handling in Advertise.
> 2. The 4.4 Renew and 4.5 Rebind sections have had major changes and rework
> (that to Marcin).
> 3. The 4.6 Confirm section was changed to remove use of Confirm for IA_PD
> (Rebind is mandated). For IA_NA and/or IA_TA only, Confirm can be used. If
> IA_PD exists, Rebind should be used (not Confirm).
> 4. Replaced 4.7.  Release Message with a 4.7  Decline Should Not
> Necessarily Trigger a Release (an issue reported by Tim Winters).
> 5. There are other minor edits (such as referencing RFC 7084 instead of
> RFC 6204).
>
> There is one outstanding issue that we'd like to get feedback on from
> folks (as well as of course the other changes made). We can discuss on the
> mailing list but will also discuss at the Toronto IETF DHC WG Session.
>
> This is the issue of which status codes Renew and Rebind should use when a
> server is unable to provide "leases" for a binding. Presently the text says
> to use NoBinding and part of that reason was that this is consistent with
> what is currently written in RFC 3315. But it may be better to use
> NoAddrsAvail/NoPrefixAvail instead of NoBinding. Marcin and I debated this
> some and here is some data regarding this issue:
>
> 1. A Request never returns NoBinding. It uses NoAddrsAvail/NoPrefixAvail.
> So, if we wanted to make Renew (and Rebind) more closely aligned ...
> 2. Existing servers (that follow 3315) will return NoBinding. Thus,
> returning this would provide a client no information as to whether the
> server was new or not - and whether to initiate a Solicit/... cycle. On the
> flip side, existing clients handle NoBinding so that could avoid issues
> with unexpected status results?
> 3. We have 4 possible responses for an IA for a Renew/Rebind when no
> 'resources'  are assigned:
> 3.a. Return NoBinding.
> 3.b. Return NoAddrsAvail/NoPrefixAvail.
> 3.c. Return an 'empty' IA (no IAADDR or IAPREFIX options).
> 3.d. Don't return the IA. (I'm not a fan of this one as it might imply to
> the client that the server doesn't know that IA.) 4. Is there any value in
> returning additional information to a client for a Rebind? For a Rebind,
> there are two possibilities as to why the server didn't assign
> addresses/prefixes:
> 4.a. The server has no resources available at the present time.
> 4.b. The server is not able to assign resources because it is not
> configured to support "rapid commit".
> So, should we consider whether these should be handled differently? For
> 4.a., if the client retries (i.e., Renew, Solicit) it may get a resource
> but may not - depends on why it isn't available and whether something has
> happened to make a resource available. For 4.b, if the client retries
> (i.e., Renew, Solicit) it would likely get the resource.
> 5. There is one other condition to consider - my original assumption for
> Renew was that the server could 'refuse' to service the client if the
> server had no record of the client (i.e., no bindings). In this case,
> returning NoBinding for all of the IA_* would be appropriate - to force the
> client to Solicit/...
>
> (If we do 'drop' NoBinding from Renew/Rebind, then this status code would
> only be used for Release/Decline Replies.)
>
> My feeling is that for Renew/Rebind:
> - We should return NoAddrsAvail/NoPrefixAvail when the server cannot
> provide the requested resources but would if it 'could'.
> - We should reserve NoBinding to trigger the client to go back to
> Solicit/... or Request. Therefore, this should only be used in conditions
> where the server wants (needs) the client to do that.
>
> If would be nice if the status codes (or empty or missing IA) had
> consistent meanings for 'all' messages and thus triggered consistent client
> actions.
>
> Putting NoAddrsAvail into the IA carried in the Reply to Renew/Rebind
> shouldn't cause problems in the clients that really follow the current
> RFC3315 as in the section 18.1.8 it clearly specifies what to do with IAs
> that contain NoAddrsAvail in the Reply message  and it doesn't
> differentiate between the types of messages in response to which the Reply
> has been received. The following paragraph:
>
> "When the client receives a Reply message in response to a Renew or
>    Rebind message, the client examines each IA independently.  For each
>    IA in the original Renew or Rebind message, the client:
>
>    -  sends a Request message if the IA contained a Status Code option
>       with the NoBinding status (and does not send any additional
>       Renew/Rebind messages)
>
>    -  sends a Renew/Rebind if the IA is not in the Reply message
>
>    -  otherwise accepts the information in the IA "
> may be a source of trouble for clients which implementers ignored the
> preceding paragraph and simply made an assumption that NoAddrsAvail is not
> returned for Renew/Rebind. On the other hand the client shouldn't fall over
> just because it gets the unexpected status code.
>
> So in principle it seems to be fine to use NoAddrsAvail/NoPrefixAvail in
> the Reply messages sent as a response to Renew/Rebind.
>
>
> Anyway, give the current draft a read and if there are concerns or
> questions (or you have a view on the issue), please send mail to the list
> ASAP.
>
> - Bernie
>
> -----Original Message-----
> From: dhcwg [mailto:[e-mail]] On Behalf Of
> [e-mail]
> Sent: Monday, June 30, 2014 12:34 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-06.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>  This draft is a work item of the Dynamic Host Configuration Working Group
> of the IETF.
>
>         Title           : Issues with multiple stateful DHCPv6 options
>         Authors         : Ole Troan
>                           Bernie Volz
>                           Marcin Siodelski
>         Filename        : draft-ietf-dhc-dhcpv6-stateful-issues-06.txt
>         Pages           : 20
>         Date            : 2014-06-30
>
> Abstract:
>    Dynamic Host Configuration Protocol for IPv6 (DHCPv6) was not written
>    with the expectation that additional stateful DHCPv6 options would be
>    developed.  IPv6 Prefix Options for Dynamic Host Configuration
>    Protocol (DHCP) version 6 shoe-horned the new options for Prefix
>    Delegation into DHCPv6.  Implementation experience of the CPE model
>    described in RFC 7084 has shown multiple issues with the DHCPv6
>    protocol in supporting multiple stateful options.  This document
>    updates RFC 3315 and RFC 3633.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-stateful-issues/
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-stateful-issues-06
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-dhcpv6-stateful-issues-06
>
>
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg
>
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg
>