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

From: [email-masked]
Date: Mon, 30 Jun 2014 09:33:51 -0700

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/

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 30 Jun 2014 16:55:59 +0000

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:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, June 30, 2014 12:34 PM
To: [email-masked]
Cc: [email-masked]
Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-06.txt

Abstract:

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.

_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: 神明達哉 <[email-masked]>
Date: Mon, 30 Jun 2014 11:04:17 -0700

At Mon, 30 Jun 2014 16:55:59 +0000,
"Bernie Volz (volz)" <[email-masked]> wrote:

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

I've just made a quick scan of the 06 version.  I'm going to take a
closer look at it later, but please let me check one high level thing
first, based on my own comments on the previous version:
http://www.ietf.org/mail-archive/web/dhcwg/current/msg15284.html

Can I assume that this draft tries to provide a generalized specification
for all current and possible IA_xx, even if the original motivation
was (in my understanding from the previous discussion) to clarify the
usage of IA_NA and IA_PA in the same DHCPv6 session?  And, if so, does
it try to provide a well-defined specification for the usage with
IA_TA and other IA_xx's?

The overall tone of the new version from a quick read seemed to
suggest that the answer is "yes" to both questions, but in some
specific cases the draft still seems to focus on /assume specific
usage (not just as an example).  Also, as for IA_TA, the 4th paragraph
of Section 1, especially its second sentence, could read as if IA_TA
is an out of scope of this specification:

   [...] IA_TA also has limited value when DHCPv6 is used for address
   assignment, as the privacy issues identified for IPv6 stateless
   address assignment ([RFC4941]) do not apply to DHCPv6 assignments.

If the intent is to also cover the usage of IA_TA, I don't see the
need for this sentence in the context of this document.

I'd like to be sure about the author's intent of these, as that would
affect how I should read the draft and possibly make comments on it.

--
JINMEI, Tatuya

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 30 Jun 2014 18:19:37 +0000

The core focus of this work is getting IA_NA & IA_PD to work well together, since that is what is used in RFC 7084.

But because we're making changes to the specifications (i.e., revised sections of 3315, 3633, and even in some cases providing text for possible use in the 3315bis work), we are indeed trying to cover all IA_* options (while we hope it includes future possible IA_* options, that is more difficult to achieve as we don't know what those might be).

>Can I assume that this draft tries to provide a generalized specification for all current and possible IA_xx

So yes.

Note however that IA_TAs are probably not widely used ... and we might even want to debate for RFC 3315bis whether to deprecate them. 3315 work was occurring when the privacy issues for IPv6 exploded and so the team then tried to accommodate this issue. But it is hard to see how DHCPv6 servers would assign the same 'interface-identifier' portion of the address when a client moves to different servers. So, is IA_TA really that necessary? Sure, if you have a fixed node that might continue to renew its IA_NA address 'forever', perhaps there may be some desire to use a different address for browsing or other applications and if stateless is prohibited, then having IA_TA might have some value.

Bottom line is that yes we are trying to accommodate all (existing) IA_* types. And, in general we've assumed that 3315 has handled IA_NA/IA_TA co-existence sufficiently, so the revised text focuses on included IA_PD handling.

If you find areas where we got something wrong (or perhaps 3315 did) regarding IA_TA (or any IA_*), please do let us know.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ????
Sent: Monday, June 30, 2014 2:04 PM
To: Bernie Volz (volz)
Cc: [email-masked]
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-06.txt

> Marcin for joining the authors to make some of those changes.

I've just made a quick scan of the 06 version.  I'm going to take a closer look at it later, but please let me check one high level thing first, based on my own comments on the previous version:
http://www.ietf.org/mail-archive/web/dhcwg/current/msg15284.html

Can I assume that this draft tries to provide a generalized specification for all current and possible IA_xx, even if the original motivation was (in my understanding from the previous discussion) to clarify the usage of IA_NA and IA_PA in the same DHCPv6 session?  And, if so, does it try to provide a well-defined specification for the usage with IA_TA and other IA_xx's?

The overall tone of the new version from a quick read seemed to suggest that the answer is "yes" to both questions, but in some specific cases the draft still seems to focus on /assume specific usage (not just as an example).  Also, as for IA_TA, the 4th paragraph of Section 1, especially its second sentence, could read as if IA_TA is an out of scope of this specification:

If the intent is to also cover the usage of IA_TA, I don't see the need for this sentence in the context of this document.

I'd like to be sure about the author's intent of these, as that would affect how I should read the draft and possibly make comments on it.

--
JINMEI, Tatuya