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

What about the other things RAs provide? Such as the routers and on-link notification ... Are RAs active in these networks or not?

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" <akostur@incognito.com> 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 <jiangsheng@huawei.com> 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
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg