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

"Bernie Volz (volz)" <volz@cisco.com> Wed, 15 August 2012 14:01 UTC

Return-Path: <volz@cisco.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 13B8721F8800 for <dhcwg@ietfa.amsl.com>; Wed, 15 Aug 2012 07:01:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level:
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V+gCRQnLYjPO for <dhcwg@ietfa.amsl.com>; Wed, 15 Aug 2012 07:01:14 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 7E96821F86F6 for <dhcwg@ietf.org>; Wed, 15 Aug 2012 07:01:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=22685; q=dns/txt; s=iport; t=1345039274; x=1346248874; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=4IW7ki/wE50KWnjtW9Y0OF97fbwbNcl96TBuXcn2Axk=; b=Dgk0LQNOzN99pCwLTJCBjP45LTS1IVNA8UdkfHD5q+gjqCmwMwIm1IMZ nZwLG+Zty0M+P9z5/FP8zkmADBYBHO9hzREjeX7lP2ZQatWF0LEMqujZZ WYAq3M8eBYhykf850+u9WxXpdXzTh/a8BSRq4V56vVpA4loBNvc3K1hlb g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgAFAEerK1CtJXG+/2dsb2JhbABFgkq3TYEHgiABAQEEEgEaTBACAQgRBAEBCxYHBzIUCQgCBAENBQgXA4drmUugS4sIhXdgA6N7gWaCXw
X-IronPort-AV: E=Sophos; i="4.77,773,1336348800"; d="scan'208,217"; a="111841183"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-4.cisco.com with ESMTP; 15 Aug 2012 14:01:13 +0000
Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q7FE1AcR022044 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 15 Aug 2012 14:01:12 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.159]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0298.004; Wed, 15 Aug 2012 09:01:11 -0500
From: "Bernie Volz (volz)" <volz@cisco.com>
To: Ted Lemon <Ted.Lemon@nominum.com>, Andre Kostur <akostur@incognito.com>
Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02
Thread-Index: AQHNePgJ6EjzoGF6j0KwHUjTOoQDGZdXH58ggAAgh9CAAdqGoIAA+BcggACPzwCAAI85gP//tRyg
Date: Wed, 15 Aug 2012 14:01:11 +0000
Message-ID: <489D13FBFA9B3E41812EA89F188F018E0F4EBE06@xmb-rcd-x04.cisco.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>
In-Reply-To: <388CD216-17F9-463E-8CDB-F084C9D43C54@nominum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [161.44.65.136]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19114.006
x-tm-as-result: No--38.587600-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E0F4EBE06xmbrcdx04ciscoc_"
MIME-Version: 1.0
Cc: dhc WG <dhcwg@ietf.org>
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: Wed, 15 Aug 2012 14:01:17 -0000

Ted:

If that is the case, why is there an IAID in the option (see below)? Shouldn't that be removed?? If we have an IAID, then the client MUST provide this option. If there is no IAID, then it may be possible to just put the option in the ORO. However, I'd personally prefer we stick with the IA_NA/IA_TA/IA_PD conventions and require this to be supplied by the client. If the server doesn't understand the option, it won't send it back in the Advertise/Reply.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         OPTION_IA_PA          |         option-length         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         IAID (4 octets)                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              T1                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              T2                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       .                                                               .
       .                          IA_PA-options                        .
       .                                                               .
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


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)?


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).


Another issue that should be addressed in the document is what a client should send when it connects to a network. How does it know that the server supports IA_PA and that it should be used, instead of the traditional IA_NA? Should a client request both? Does it send some kind of probe (Solicit with IA_PA [perhaps only in the ORO]) - and what does it do if it doesn't get any response; try again for IA_NA.

Personally, I do NOT think this work is ready and needs more clarity.


-          Bernie

From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Ted Lemon
Sent: Wednesday, August 15, 2012 9:15 AM
To: Andre Kostur
Cc: dhc WG
Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02

On Aug 15, 2012, at 12:42 AM, Andre Kostur wrote:
I think that if the device wants a PA, it should supply an IA_PA in
its Solicit.  The device needs to specify an IAID.  An ORO is
insufficient.

The prefix is not necessarily specific to an individual client-it's not a prefix delegation.   So I don't think an IAID is necessary at all.