Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02
Sheng Jiang <jiangsheng@huawei.com> Thu, 16 August 2012 03:52 UTC
Return-Path: <jiangsheng@huawei.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEDE611E80E8 for <dhcwg@ietfa.amsl.com>; Wed, 15 Aug 2012 20:52:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.388
X-Spam-Level:
X-Spam-Status: No, score=-6.388 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5vJKfZBCL7By for <dhcwg@ietfa.amsl.com>; Wed, 15 Aug 2012 20:52:12 -0700 (PDT)
Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 04ABC11E80E4 for <dhcwg@ietf.org>; Wed, 15 Aug 2012 20:52:11 -0700 (PDT)
Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath) with ESMTP id AJL41635; Wed, 15 Aug 2012 19:52:11 -0800 (PST)
Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 15 Aug 2012 20:48:07 -0700
Received: from SZXEML431-HUB.china.huawei.com (10.72.61.39) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 15 Aug 2012 20:48:05 -0700
Received: from szxeml545-mbx.china.huawei.com ([169.254.1.140]) by szxeml431-hub.china.huawei.com ([10.72.61.39]) with mapi id 14.01.0323.003; Thu, 16 Aug 2012 11:48:01 +0800
From: Sheng Jiang <jiangsheng@huawei.com>
To: "Bernie Volz (volz)" <volz@cisco.com>, Andre Kostur <akostur@incognito.com>
Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02
Thread-Index: AQHNePgJ6EjzoGF6j0KwHUjTOoQDGZdXH58ggAAgh9CAAdqGoIAA+Bcg//+14QCAAI85gIAADPCAgAE0l2D//4WvgIAAHvOAgACIrLA=
Date: Thu, 16 Aug 2012 03:48:00 +0000
Message-ID: <5D36713D8A4E7348A7E10DF7437A4B9239F067D3@szxeml545-mbx.china.huawei.com>
References: <2DCA645F-CDDF-4311-8417-3A9771AD3F71@nominum.com> <90903C21C73202418A48BFBE80AEE5EB0D028F@xmb-aln-x06.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B9239F0504A@szxeml545-mbx.china.huawei.com> <90903C21C73202418A48BFBE80AEE5EB0D40AF@xmb-aln-x06.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B9239F060CC@szxeml545-mbx.china.huawei.com> <CAL10_BrrHJSrP88q6S3o6YGWmR574djWEuOBowCq5pc8K0-a8Q@mail.gmail.com> <388CD216-17F9-463E-8CDB-F084C9D43C54@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F4EBE06@xmb-rcd-x04.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B9239F066A2@szxeml545-mbx.china.huawei.com>, <CAL10_BpGiqOkk4by-rkfW4WT7R47_D-1uk35L7EXCmcPnQKQEw@mail.gmail.com> <0E81DDB0-29DA-4B8F-A336-FDE9FDA663D2@cisco.com>
In-Reply-To: <0E81DDB0-29DA-4B8F-A336-FDE9FDA663D2@cisco.com>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.99.31]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: dhc WG <dhcwg@ietf.org>, Ted Lemon <Ted.Lemon@nominum.com>
Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dhcwg>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Aug 2012 03:52:13 -0000
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" <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
- [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 Ted Lemon
- Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 Gaurav Halwasia (ghalwasi)
- Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 Sheng Jiang
- Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 Liubing (Leo)
- Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 Sheng Jiang
- Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 Gaurav Halwasia (ghalwasi)
- Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 Liubing (Leo)
- Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 Sheng Jiang
- Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 Andre Kostur
- Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 Fuyu (Eleven)
- Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 Sheng Jiang
- Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 Sheng Jiang
- Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 Sean Shen 沈烁
- Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 Ted Lemon
- Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 Ted Lemon
- Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 Gaurav Halwasia (ghalwasi)
- Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 Ted Lemon
- Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 Bernie Volz (volz)
- Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 Ted Lemon
- Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 Gaurav Halwasia (ghalwasi)
- Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 Gaurav Halwasia (ghalwasi)
- Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 Bernie Volz (volz)
- Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 Sheng Jiang
- Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 Ted Lemon
- Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 Sheng Jiang
- Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 Sheng Jiang
- Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 Andre Kostur
- Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 Bernie Volz (volz)
- Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 Sheng Jiang
- Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 Donald Eastlake
- Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 Sheng Jiang
- Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 Sheng Jiang