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

[Sheng Jiang <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] 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" <[e-mail]>
>>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 <[e-mail]>
>>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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/dhcwg
>
>_______________________________________________
>dhcwg mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/dhcwg