Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-03

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 22 Aug 2012 03:38:29 +0000

A few comments from a quick look at the 03 document:

- An Advertise should NEVER assign anything. A Reply is the only thing that can do that. 

       The DHCPv6 server assigns one or more prefixes to the host in
       Advertise messages or in the Reply messages responding to the
       prefix requests from the hosts.

The assignment doesn't occur until the Reply (note also the "or"). This is very bad and we should not be misleading people that all they need is Solicit/Advertise.

- This document still fails to clarify the on-link status of the PA prefix (I would assume it is NOT on-link unless so advertised in an RA). I haven't looked back at the stateless autoconfiguration document to see if there is anything else that a RA Prefix Information Option communicates that might also be missing - obviously the A (stateless) isn't need since it is implicit in the IA_PA.

- I would think it would improve things to move the 6. Applicability section to earlier in the document (for example, after section 1).

- I think this document needs to clarify what a host does if the same prefix is communicated (for essentially stateless usage) via both RAs and DHCPv6. For example, must it continue to renew it with the DHCP server.

- There probably needs to be some text regarding some considerations for DHCP servers and clients. For example, if a IA_PA capable client connects to a network, and the DHCP server is not IA_PA capable, the Solicit will result in no or Advertises without IA_PAs. A client could now continue Soliciting (with appropriate retransmissions) or it could 'failover' to doing IA_NA/IA_TA requests? Or perhaps just wait for stateless (RS/RA) to either provide it stateless autoconfiguration or indicate that it should do DHCP (with IA_NA/IA_TA)? Perhaps are reasons for each of these behaviors. Or, there may be guidance about when to use IA_PAs in Solicits and when not? For example, use it for point-to-point interfaces only? Note that I'm not promoting one choice over another - that is for you (and the WG) to decide.

- Perhaps not absolutely necessary (since I would hope it obvious), but it may be useful to indicate that the PD_EXCLUDE (RFC 6603) option may not be encapsulated in the IAPREFIX options that are encapsulated in an IA_PD? (RFC 6603 is pretty dependent on PD.)

- Bernie

-----Original Message-----
From: Sheng Jiang [mailto:[email-masked]] 
Sent: Tuesday, August 21, 2012 10:05 PM
To: Bernie Volz (volz); Andre Kostur
Cc: dhc WG; Ted Lemon
Subject: RE: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02

The authors have submitted an updated 03 version of this draft according to the latest discussion on the mail list.

Among with minor modifications, the authors have largely rewritten the introduction/motivation section, hoping this would clarify the target scenarios.

http://tools.ietf.org/html/draft-ietf-dhc-host-gen-id-03

Discussion/review/comments are welcome.

Best regards,

Sheng

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf
>Of Sheng Jiang
>Sent: Thursday, August 16, 2012 11:48 AM
>To: Bernie Volz (volz); Andre Kostur
>Cc: dhc WG; Ted Lemon
>Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02
>
>Hi, Bernie and Andre
>
>Thanks for your comments. Actually, we are quite open to discuss. The only
>reason we request WGLC is there is no any discussion for this draft for last 12
>months and we have addressed all comments we received.
>
>Since you have raised new discussion, we are happy to delay the process till
>all open issues get addressed. This is good for our work to be real mature. :)
>
>See my reply in lines.
>
>Sheng
>
>>What about the other things RAs provide? Such as the routers and on-link
>>notification ... Are RAs active in these networks or not?
>
>This work does NOT replace neighbor discovery. RA is active in our target
>network. ND is mainly for reachability/routing purpose.
>
>This work is to make the address configuration all by DHCPv6, rather than part
>by RA, part by DHCPv6. With the assumption that DHCPv6 takes over all
>address configuration, assigning 128-bit address is insufficient. Some host
>want to use self-generated address, CGA is only one example, others
>including EUI64 and privacy address.
>
>This work is a generic prefix assignment/announcement mechanism. It is
>alternative of RA prefix assignment/announcement.
>
>
>draft-ietf-dhc-secure-dhcpv6 is nothing to do with address configuration. It is
>AFTER CGA addresses generated, using them to protect DHCPv6 message
>exchanging.
>
>draft-ietf-dhc-cga-config-dhcpv6 is specific CGA configuration. Since we
>separated prefix assignment to be this generic mechanism, that draft is only
>focusing on CGA approve process. However, if the discussion think prefix
>assignment is only meaningful for CGA, we have no problem to combine this
>back to CGA configuration draft.
>
>Let's first discuss the requirement/problem first. We can come back to
>technical details later.
>
>Regards,
>
>Sheng
>
>>Also how is the client's assignment of addresses considered
>>DHCPv6-managed?
>>
>>How is this any different from stateless?
>>
>>The only difference with this over normal stateless is that you could give
>each
>>client its own prefix, whereas RAs are sent to all devices on the link. But I
>>don't recall the document mentioning such a network (and in some cases
>>where this might occur, usually there are tunnels involved and protocols such
>>as ppp). And you would have to describe such a network and explain why RSs
>>and RAs are insufficent or not usuable/pratical.
>>
>>When the working group adopts a document to work on, that does not
>mean
>>it will necessarily advance. Sometimes not all of the issues are well
>>understood early in the process. There are other cases where it can take
>many
>>years to work out the details and address the concerns before the document
>>is ready. The process can be frustrating and demotivating. But the result is
>>usually for the best.
>>
>>Also, as CGAs are mentioned as one possible usage model, I think it would
>>again be important to understand why the other works in this area
>>(draft-ietf-dhc-cga-config-dhcpv6 and draft-ietf-dhc-secure-dhcpv6) are not
>>appropriate or do not cover all of the requirements - and it might be worth
>>considering working with those authors? Note also that in normal DHCPv6,
>>clients may request explicit addresses and so using CGA addresses via
>DHCPv6
>>isn't impossible (some servers do require a range of addresses to be
>>configured just like for v4, but I consider that approach to limit what v6 has
>to
>>offer -- the server I work on does not have this restriction).
>>
>>I can agree with you that the world isn't as simple as we would like - there
>are
>>plenty of devices that only support stateless and this makes running a "fully"
>>DHCPv6 managed network where you don't have total control of the devices
>>that may connect impossible. But building more complexity and choices into
>>DHCPv6 hardly seems like the a good approach to solving this since it will be
>>even longer before all of the devices support these new configuration
>models
>>- or some may chose not to implement DHCPv6 at all.
>>
>>Anyway, if I haven't said it before or it isn't yet clear, I have serious
>objections
>>to advancing this work in its current form and given its current motivation. If
>>the rational for needing these capabilities and how they are used between
>>clients, relays, and servers and the network are explained, I will be happy to
>>remove my objections.
>>
>>- Bernie
>>
>>On Aug 15, 2012, at 9:08 PM, "Andre Kostur" <[email-masked]>
>>wrote:
>>
>>> Leaving aside the issue of whether this "prefix announcement" should
>>> be carried over DHCPv6, I wonder if trying to fit this into an
>>> Identity Association isn't quite right since there is no identity to
>>> be managed?   Perhaps a cleaner solution would be for the device to
>>> ask for an IAPREFIX in an ORO in an Information-Request, and the
>>> server can reply with an IAPREFIX (that isn't in any IA_* option).
>>>
>>> Having said that, I'm with Ted in that I don't quite grasp why we're
>>> trying to do this.  It the network is "fully DHCPv6-managed", wouldn't
>>> that mean that the administrators would want to control the address
>>> generation instead of leaving it up to the client to do with it as it
>>> will?
>>>
>>> On Wed, Aug 15, 2012 at 5:49 PM, Sheng Jiang <[email-masked]>
>>wrote:
>>>>
>>>> Hi, Bernie,
>>>>
>>>>
>>>>
>>>> Thanks for your comments. See my reply in lines.
>>>>
>>>>
>>>>
>>>> Sheng
>>>>
>>>>
>>>>
>>>> I’d also suggest the following be clarified (section 4, bullet 2):
>>>>
>>>>
>>>>
>>>>      If there is not a proper prefix available, a status-
>>>>
>>>>      code is returned to the host and the procedure is terminated.
>>>>
>>>>
>>>>
>>>> What status code and where is this status code returned. Let’s hope it
>>>> follows the IA_PD conventions (especially if we keep the IAID in the
>IA_PA).
>>>> There is no new status code requested, do apparently it is one of the
>>>> existing codes (RFC 3315/3633)?
>>>>
>>>>
>>>>
>>>> <Sheng> It is the existing NoPrefixAvail status code, defined in RFC 3633.
>>>> I have just added an explicit explanation for this.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> This work also seems to be to replacing Router Solicitation/Router
>>>> Advertisement messages to advertise the prefixes (for stateless
>>>> autoconfiguration). Do we really want this. And, might not this be
>>something
>>>> to discuss in a slightly wider IETF audience. Perhaps it has already been (I
>>>> haven’t followed this work that closely).
>>>>
>>>>
>>>>
>>>> <Sheng> It is the assumption we take. I believe we had the WG
>consensus,
>>>> by adopting as WG document. Because this only happens in a fully
>>>> DHCPv6-managed network, does not impact any other network that use
>>RA for
>>>> SLACC, so I think discussion in DHC is enough.
>>>
>>> --
>>> Andre Kostur
>>> _______________________________________________
>>> dhcwg mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/dhcwg
>
>_______________________________________________
>dhcwg mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Sheng Jiang <[email-masked]>
Date: Mon, 27 Aug 2012 03:40:10 +0000

Hi, Bernie,

Thanks so much for your comments. They help a lot for improving the quality of this draft. I am making the correspondent changes. See replies in lines.

I also attached an ongoing version. It will only submit after the discussion get stable.

Best regards,

Sheng

>The assignment doesn't occur until the Reply (note also the "or"). This 
>is very bad and we should not be misleading people that all they need 
>is Solicit/Advertise.

Yes, you are right. I have removed assignment in advertise message.

>- This document still fails to clarify the on-link status of the PA 
>prefix (I would assume it is NOT on-link unless so advertised in an 
>RA). I haven't looked back at the stateless autoconfiguration document 
>to see if there is anything else that a RA Prefix Information Option 
>communicates that might also be missing
>- obviously the A (stateless) isn't need since it is implicit in the IA_PA.

I don't think PA should match all RA Prefix Information. On-link status is for the reachability, which IA_PA does not care. Different from draft-droms-dhc-dhcpv6-default-router, we don't want to replace ND reachability and routing functions. However, I have added the below text as explanation into the draft.

"Comparing with Prefix Information Option in ND, Section 4.6.2 of RFC4861, the IA_PA option does not provide L flag and A flag.  The A (autonomous address-configuration flag) isn't need obviously because the IA_PA is implicit for stateless address configuration. Because the IA_PA is only address relevant, it does not relevant to reachability or routing and the DHCPv6 server may not sure the on-link state. So L (on-Link) flag is not include. The DHCPv6 client should treat the prefix as same as L flag not set, which makes no statement about on-link or off-link properties of the prefix."

>- I would think it would improve things to move the 6. Applicability 
>section to earlier in the document (for example, after section 1).

Have done this.

>- I think this document needs to clarify what a host does if the same 
>prefix is communicated (for essentially stateless usage) via both RAs 
>and DHCPv6. For example, must it continue to renew it with the DHCP server.

I don't think this should be an issue. In principle, AI_PA and RA Prefix Information Option should NOT be used for the same prefix. Network operator should avoid this in network design. However, even this happens, it should not be harmful. Implementation can use any one of it and safely ignore another one. Why bother?

>- There probably needs to be some text regarding some considerations 
>for DHCP servers and clients. For example, if a IA_PA capable client 
>connects to a network, and the DHCP server is not IA_PA capable, the 
>Solicit will result in no or Advertises without IA_PAs. A client could 
>now continue Soliciting (with appropriate retransmissions) or it could 
>'failover' to doing IA_NA/IA_TA requests? Or perhaps just wait for 
>stateless (RS/RA) to either provide it stateless autoconfiguration or 
>indicate that it should do DHCP (with IA_NA/IA_TA)? Perhaps are reasons 
>for each of these behaviors. Or, there may be guidance about when to 
>use IA_PAs in Solicits and when not? For example, use it for 
>point-to-point interfaces only? Note that I'm not promoting one choice over another - that is for you (and the WG) to decide.

Personally, I believe this consideration is more implementer choices, rather than standard work. However, I have added the below text.

"If an IA_PA capable client connects to a network, and the DHCPv6 server is not IA_PA capable, the Solicit or Request message with IA_PA Option will result in no Reply, Reply without IA_PAs, or Reply with a Status Code containing UnspecFail. The client MAY decide the network does not support IA_PA immediately or after a period of soliciting (with limited retransmissions times). Then, it MAY 'failover' to IA_NA/IA_TA requests."

>- Perhaps not absolutely necessary (since I would hope it obvious), but 
>it may be useful to indicate that the PD_EXCLUDE (RFC 6603) option may 
>not be encapsulated in the IAPREFIX options that are encapsulated in an 
>IA_PD? (RFC
>6603 is pretty dependent on PD.)

Have added this statement into the draft.

Best regards,

Sheng