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

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

Hi:

This is “should”. That allows for cases where a client may want to use multiple sessions to different servers. This might well be the case if multiple provisioning domains were in play – see section 4.8. But this is an  area of potential future work …

If a client decides to start multiple sessions, why would it then combine the two separate sessions? I think it should keep the transactions completely separate (even when reaching the Rebind ‘state’). If it doesn’t keep things separate, it could very well end up with conflicting answers – it all depends on what each server knows about what the other has and how it responds (respond with “NoBinding”, respond with 0 lifetimes, respond with “NotOnLink”, …).

We do NOT cover this since we do NOT expect clients will generally want to do this. But there is nothing that prohibits this based on RFC 3315 and this draft.

I don’t know if you are suggesting any changes to the text, if so, please provide those suggestions.


-          Bernie

From: Cong Liu [mailto:[e-mail]]
Sent: Monday, July 14, 2014 5:14 AM
To: Bernie Volz (volz)
Cc: [e-mail]
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-06.txt

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]<mailto:[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]<mailto:[e-mail]>] On Behalf Of [e-mail]<mailto:[e-mail]>
Sent: Monday, June 30, 2014 12:34 PM
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[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<http://tools.ietf.org>.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
dhcwg mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
dhcwg mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/dhcwg