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

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

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: [e-mail] [mailto:[e-mail]] On Behalf Of ????
Sent: Monday, June 30, 2014 2:04 PM
To: Bernie Volz (volz)
Cc: [e-mail]
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-06.txt

At Mon, 30 Jun 2014 16:55:59 +0000,
"Bernie Volz (volz)" <[e-mail]> 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