From Ted.Lemon@nominum.com Fri May 4 12:44:50 2012 Return-Path: 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 7BAC721E8050 for ; Fri, 4 May 2012 12:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.537 X-Spam-Level: X-Spam-Status: No, score=-106.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 ds8P4lYin9ew for ; Fri, 4 May 2012 12:44:49 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id 76F8621E8029 for ; Fri, 4 May 2012 12:44:49 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKT6QxsTrusenKl9i34Sjvy16ESs++apXC@postini.com; Fri, 04 May 2012 12:44:49 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id A6A701B8245 for ; Fri, 4 May 2012 12:44:48 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 9E77B19005C for ; Fri, 4 May 2012 12:44:48 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Fri, 4 May 2012 12:44:48 -0700 From: Ted Lemon To: DHC WG Thread-Topic: Call for adoption: draft-yeh-dhc-dhcpv6-authorization-opt Thread-Index: AQHNItfRPqNlqZKpqU+ca4CGj8EPIZa6jGGA Date: Fri, 4 May 2012 19:44:47 +0000 Message-ID: <7283636E-1730-41EA-912E-35B32C76B999@nominum.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <5B63EBE1D998F0408B8D0639B94A35E1@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] Call for adoption: draft-yeh-dhc-dhcpv6-authorization-opt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 19:44:50 -0000 On Apr 25, 2012, at 7:37 AM, Ted Lemon wrote: > One of the authors of this draft has requested a formal call for adoption= . There was substantial support for the work in the DHC working group mee= ting in Paris, and no objections. The idea is to have a RADIUS option for= DHCPv6, similar to the functionality present in DHCPv4. > We will make a determination of consensus on May 9. Nine people were in favor of adopting this work and said so on the mailing = list. Nobody spoke to oppose doing the work. So there is consensus to a= dopt it. Leaf agreed to change the name of the draft to make it more clea= r that it's about radius options. Leaf, please publish a -00 version as a working group draft when you are re= ady. Thanks! From internet-drafts@ietf.org Sun May 6 20:26:47 2012 Return-Path: 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 08F1821F84EF; Sun, 6 May 2012 20:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.507 X-Spam-Level: X-Spam-Status: No, score=-102.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 cCndKXy-Fh5x; Sun, 6 May 2012 20:26:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 549F221F8443; Sun, 6 May 2012 20:26:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120507032646.31534.49058.idtracker@ietfa.amsl.com> Date: Sun, 06 May 2012 20:26:46 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 03:26:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Dynamic Host Configuration Working Gr= oup of the IETF. Title : RADIUS Option for DHCPv6 Relay Agents on Broadband Acces= s Server Author(s) : Leaf Y. Yeh Mohamed Boucadair Ted Lemon Filename : draft-ietf-dhc-dhcpv6-radius-opt-00.txt Pages : 9 Date : 2012-05-06 The DHCPv6 RADIUS option provides a communication mechanism between relay agent and the server. This mechanism can help the centralized DHCPv6 server to select the right configuration for the client based on the authorization information received from a separate RADIUS server which is not located at the same place of DHCPv6 server in the cases where the NAS acts as DHCPv6 relay agent and RADIUS client simultaneously. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-radius-opt-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-radius-opt-00.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-radius-opt/ From internet-drafts@ietf.org Sun May 6 20:28:57 2012 Return-Path: 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 BF4B621F853C; Sun, 6 May 2012 20:28:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.52 X-Spam-Level: X-Spam-Status: No, score=-102.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 GDec+88T+ZZh; Sun, 6 May 2012 20:28:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34FC921F84EF; Sun, 6 May 2012 20:28:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120507032857.32055.91989.idtracker@ietfa.amsl.com> Date: Sun, 06 May 2012 20:28:57 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 03:28:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Dynamic Host Configuration Working Gr= oup of the IETF. Title : Issues with multiple stateful DHCPv6 options Author(s) : Ole Troan Bernie Volz Filename : draft-ietf-dhc-dhcpv6-stateful-issues-00.txt Pages : 8 Date : 2012-05-06 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) was not written with the expectation that additional stateful DHCPv6 options would be developed. IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6 shoe-horned the new options for Prefix Delegation into DHCPv6. Implementation experience of the CPE model described in has shown multiple issues with the DHCPv6 protocol in supporting multiple stateful options. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-stateful-issues-0= 0.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-stateful-issues-00= .txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-stateful-issues/ From Ted.Lemon@nominum.com Sun May 6 21:34:56 2012 Return-Path: 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 2DF8E21F853D for ; Sun, 6 May 2012 21:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.538 X-Spam-Level: X-Spam-Status: No, score=-106.538 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 5PHqRK3Z0QAM for ; Sun, 6 May 2012 21:34:54 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id 243A721F84A0 for ; Sun, 6 May 2012 21:34:53 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKT6dQ60r+Sgs392H+KwOykcARqNBIfaTz@postini.com; Sun, 06 May 2012 21:34:53 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id F05501B82AC for ; Sun, 6 May 2012 21:34:50 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id E361F19005C for ; Sun, 6 May 2012 21:34:50 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Sun, 6 May 2012 21:34:50 -0700 From: Ted Lemon To: DHC WG Thread-Topic: [dhcwg] Call for adoption: draft-jiang-addr-registration Thread-Index: AQHNHQQyZiojdrZahUGpIG8DE28dmpa+UMoA Date: Mon, 7 May 2012 04:34:50 +0000 Message-ID: <6F196951-EDD7-44A0-AF5C-B55DBF9FC780@nominum.com> References: <35A22BA8-1475-4B97-A53B-F1719E3AA5A9@nominum.com> In-Reply-To: <35A22BA8-1475-4B97-A53B-F1719E3AA5A9@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_6F196951EDD744A0AF5CB55DBF9FC780nominumcom_" MIME-Version: 1.0 Subject: Re: [dhcwg] Call for adoption: draft-jiang-addr-registration X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 04:34:56 -0000 --_000_6F196951EDD744A0AF5CB55DBF9FC780nominumcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Apr 17, 2012, at 9:40 PM, Ted Lemon > wrote: We will determine consensus on May 1, 2012. Nine were in favor of adopting, none opposed, so the working group has adop= ted this as a work item. --_000_6F196951EDD744A0AF5CB55DBF9FC780nominumcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <80EA3BD308AD8F45898CB9CE4A378265@nominum.com> Content-Transfer-Encoding: quoted-printable
On Apr 17, 2012, at 9:40 PM, Ted Lemon <Ted.Lemon@nominum.com> wrote:
We will determine consensus on May 1, 2012.

Nine were in favor of adopting, none opposed, so the working group has= adopted this as a work item.

--_000_6F196951EDD744A0AF5CB55DBF9FC780nominumcom_-- From Ted.Lemon@nominum.com Sun May 6 21:37:23 2012 Return-Path: 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 2A09021F84A0 for ; Sun, 6 May 2012 21:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.54 X-Spam-Level: X-Spam-Status: No, score=-106.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 TK1so2SKl0Ik for ; Sun, 6 May 2012 21:37:22 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id E7B4121F8468 for ; Sun, 6 May 2012 21:37:19 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKT6dRf5xloY9TQRu1tJSW5UMFh87iOfsF@postini.com; Sun, 06 May 2012 21:37:20 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 0DE2D1B82AC for ; Sun, 6 May 2012 21:37:19 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 0637419005C for ; Sun, 6 May 2012 21:37:19 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Sun, 6 May 2012 21:37:18 -0700 From: Ted Lemon To: DHC WG Thread-Topic: WGLC: draft-ietf-dhc-secure-dhcpv6 Thread-Index: AQHNLAsVRkeC+DGqZUSiKnkXQXYkxw== Date: Mon, 7 May 2012 04:37:18 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <62C80288D62A9940962F45B078437901@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dhcwg] WGLC: draft-ietf-dhc-secure-dhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 04:37:23 -0000 In the Paris meeting a show of hands indicated that the group favored bring= ing this document to last call. So this is the last call for this documen= t. If you are in favor of advancing it, and have read it, please say so. = If you think it needs work, please send text or suggestions. If you don= 't think it should advance, please say so. We will determine consensus on May 21. From internet-drafts@ietf.org Mon May 7 18:28:02 2012 Return-Path: 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 62B4221F865B; Mon, 7 May 2012 18:28:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.442 X-Spam-Level: X-Spam-Status: No, score=-102.442 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 688vJ-wCp0pY; Mon, 7 May 2012 18:28:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC21A21F8638; Mon, 7 May 2012 18:28:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120508012801.24316.25103.idtracker@ietfa.amsl.com> Date: Mon, 07 May 2012 18:28:01 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-addr-registration-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 01:28:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Dynamic Host Configuration Working Gr= oup of the IETF. Title : A Generic IPv6 Addresses Registration Solution Using DHC= Pv6 Author(s) : Sheng Jiang Gang Chen Filename : draft-ietf-dhc-addr-registration-00.txt Pages : 10 Date : 2012-05-07 In the IPv6 address allocation scenarios, host self-generated addresses are notionally conflicted with the network managed address architecture. These addresses need to be registered in the networking management plate for the purposes of central address administration. This document introduces a generic address registration solution using DHCPv6, and defines one new ND option and one new DHCPv6 option in order to propagate the solicitations of registering self-generated addresses. The registration procedure reuses the existing IA_NA in the DHCPv6 protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-addr-registration-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dhc-addr-registration-00.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-addr-registration/ From madi@cnnic.cn Mon May 7 20:48:28 2012 Return-Path: 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 38C7F21F85D1 for ; Mon, 7 May 2012 20:48:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.755 X-Spam-Level: * X-Spam-Status: No, score=1.755 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753] 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 34dbcM8nfR9R for ; Mon, 7 May 2012 20:48:27 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id D498621F8562 for ; Mon, 7 May 2012 20:48:25 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: madi@cnnic.cn Received: from unknown127.0.0.1 (HELO user-think) (127.0.0.1) by 127.0.0.1 with SMTP; Tue, 08 May 2012 11:48:18 +0800 Date: Tue, 8 May 2012 11:48:19 +0800 From: "Di Ma" To: "DHC WG" X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.90[cn] Mime-Version: 1.0 Message-ID: <201205081148191100934@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart174073501523_=----" Subject: [dhcwg] Fw: WGLC: draft-ietf-dhc-secure-dhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: madi List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 03:48:28 -0000 This is a multi-part message in MIME format. ------=_001_NextPart174073501523_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 Q29uc2lkZXJpbmcgREhDUHY2IGlzIHNvbWVob3cgb2YgYmlnIGltcG9ydGFuY2UgaW4gdGhlIGVy YSBvZiBJUHY2LCBDR0EsIGFzIGEgd2VsbC1mYXNoaW9uZWQgSVB2NiBhZGRyZXNzLCBpcyBnb2lu ZyB0byBwcm90ZWN0IERIQ1B2NiBhd2F5IGZyb20gdmFyaW91cyBhdHRhY2tzLiBTb21lIGVmZm9y dHMgb24gdGhlIHN0YW5kYXJkaXphdGlvbiBvZiByZWxhdGVkIHRlY2huaXF1ZXMgc2hvdWxkIGJl IG1hZGUuIA0KSSBhbSBpbiBmYXZvciBvZiBhZHZhbmNpbmcgdGhpcyBkb2N1bWVudC4NCg0KDQoN Cg0KRGkgTWEgDQpDTk5JQyBBZHZhbmNlZCBSZXNlYXJjaCBEZXBhcnRtZW50DQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkNoaW5hIEludGVybmV0 IE5ldHdvcmsgSW5mb3JtYXRpb24gQ2VudGVyDQpUZWw6ICg4NjEwKS01ODgxMzIxNg0KSHR0cHM6 Ly93d3cuY25uaWMuY24NCkFkZDogNCwgU291dGggNHRoIFN0cmVldCwgWmhvbmdndWFuY3VuDQpI YWlkaWFuIERpc3RyaWN0LCBCZWlqaW5nDQpQLlIuQ2hpbmEgMTAwMTkwDQpQT0I6IEJlaWppbmcg MzQ5LCBCcmFuY2ggNg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KDQpGcm9tOiBUZWQgTGVtb24NCkRhdGU6IDIwMTItMDUtMDcgMTI6MzcNClRv OiBESEMgV0cNClN1YmplY3Q6IFtkaGN3Z10gV0dMQzogZHJhZnQtaWV0Zi1kaGMtc2VjdXJlLWRo Y3B2Ng0KSW4gdGhlIFBhcmlzIG1lZXRpbmcgYSBzaG93IG9mIGhhbmRzIGluZGljYXRlZCB0aGF0 IHRoZSBncm91cCBmYXZvcmVkIGJyaW5naW5nIHRoaXMgZG9jdW1lbnQgdG8gbGFzdCBjYWxsLiAg IFNvIHRoaXMgaXMgdGhlIGxhc3QgY2FsbCBmb3IgdGhpcyBkb2N1bWVudC4gICBJZiB5b3UgYXJl IGluIGZhdm9yIG9mIGFkdmFuY2luZyBpdCwgYW5kIGhhdmUgcmVhZCBpdCwgcGxlYXNlIHNheSBz by4gICBJZiB5b3UgdGhpbmsgaXQgbmVlZHMgd29yaywgcGxlYXNlIHNlbmQgdGV4dCBvciBzdWdn ZXN0aW9ucy4gICBJZiB5b3UgZG9uJ3QgdGhpbmsgaXQgc2hvdWxkIGFkdmFuY2UsIHBsZWFzZSBz YXkgc28uDQoNCldlIHdpbGwgZGV0ZXJtaW5lIGNvbnNlbnN1cyBvbiBNYXkgMjEuDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpkaGN3ZyBtYWlsaW5n IGxpc3QNCmRoY3dnQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2RoY3dn ------=_001_NextPart174073501523_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Considering DHCPv6 is somehow of big im= portance in the era of IPv6, CGA, as&nb= sp;a well-fashioned IPv6 address, is going t= o protect DHCPv6 away from various attacks.&= nbsp;Some efforts on the standardization of = related techniques should be made. 
I am in favor of advancing this do= cument.
 
Di Ma

CNNIC Advanced Research=20 Department
___________________________________________________

China Internet Network Information=20 Center
Tel: (8610)-58813216
Https://www.cnnic.cn

Add: 4, South 4th Street,=20 Zhongguancun
Haidian District, Beijing
P.R.China 100190

POB: Beijing 349, Branch 6
____________________________________________________<= /FONT>

 
Date: 2012-05-07 12:37
To: DHC WG
Subject: [dhcwg] WGLC:=20 draft-ietf-dhc-secure-dhcpv6
In the Paris meeting a show of han= ds indicated that the group favored bringing=  this document to last call.   So&= nbsp;this is the last call for this doc= ument.   If you are in favor of&nb= sp;advancing it, and have read it, please&nb= sp;say so.   If you think it needs=  work, please send text or suggestions. = ;  If you don't think it should ad= vance, please say so.
 
We will determine consensus on May 21.<= /DIV>
 
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg
------=_001_NextPart174073501523_=------ From Ted.Lemon@nominum.com Wed May 9 08:08:04 2012 Return-Path: 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 F01F411E80A4 for ; Wed, 9 May 2012 08:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.541 X-Spam-Level: X-Spam-Status: No, score=-106.541 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 GPAnUTSuHigh for ; Wed, 9 May 2012 08:08:04 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE3411E8097 for ; Wed, 9 May 2012 08:08:03 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKT6qIUyy8uHx3QnQfktVDln8eggJIE49S@postini.com; Wed, 09 May 2012 08:08:04 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id E90351B82F6 for ; Wed, 9 May 2012 08:08:02 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id DF22B190060 for ; Wed, 9 May 2012 08:08:02 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Wed, 9 May 2012 08:08:03 -0700 From: Ted Lemon To: DHC WG Thread-Topic: [dhcwg] Call for adoption: draft-yeh-dhc-dhcpv6-authorization-opt Thread-Index: AQHNLfWHEz5HABkqUkOYXH2jAMxLWg== Date: Wed, 9 May 2012 15:08:02 +0000 Message-ID: References: <7283636E-1730-41EA-912E-35B32C76B999@nominum.com> In-Reply-To: <7283636E-1730-41EA-912E-35B32C76B999@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_A8D3DE0BDD6F4104BC81785FB29B329Enominumcom_" MIME-Version: 1.0 Subject: Re: [dhcwg] Call for adoption: draft-yeh-dhc-dhcpv6-authorization-opt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 15:08:05 -0000 --_000_A8D3DE0BDD6F4104BC81785FB29B329Enominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On May 4, 2012, at 3:44 PM, Ted Lemon > wrote: Nine people were in favor of adopting this work and said so on the mailing = list. Nobody spoke to oppose doing the work. So there is consensus to a= dopt it. Leaf agreed to change the name of the draft to make it more clea= r that it's about radius options. Oops. I just realized that I closed the call for adoption five days early= . If somebody had objections and didn't voice them because of this, pleas= e let me know. I'm assuming nobody did, but this was a mistake, and I don't want to just l= eave it unacknowledged or miss the opportunity to correct it. Sorry about= this! --_000_A8D3DE0BDD6F4104BC81785FB29B329Enominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <0091328070D06141B165273E7D8DF2A6@nominum.com> Content-Transfer-Encoding: quoted-printable
On May 4, 2012, at 3:44 PM, Ted Lemon <Ted.Lemon@nominum.com> wrote:
Nine people were in favor of adopting this work and said so on the mailing list= .   Nobody spoke to oppose doing the work.   So there i= s consensus to adopt it.   Leaf agreed to change the name of the = draft to make it more clear that it's about radius options.

Oops.   I just realized that I closed the call for adoption five = days early.   If somebody had objections and didn't voice them because= of this, please let me know.

I'm assuming nobody did, but this was a mistake, and I don't want to j= ust leave it unacknowledged or miss the opportunity to correct it.   S= orry about this!

--_000_A8D3DE0BDD6F4104BC81785FB29B329Enominumcom_-- From eleven.fuyu@huawei.com Thu May 10 02:22:44 2012 Return-Path: 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 04AD721F8478 for ; Thu, 10 May 2012 02:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599] 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 vFZiyCdJnmgH for ; Thu, 10 May 2012 02:22:43 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 49B6421F855A for ; Thu, 10 May 2012 02:22:43 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFT43559; Thu, 10 May 2012 05:22:43 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 10 May 2012 02:20:04 -0700 Received: from SZXEML437-HUB.china.huawei.com (10.72.61.72) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 10 May 2012 02:20:03 -0700 Received: from SZXEML512-MBS.china.huawei.com ([169.254.6.47]) by szxeml437-hub.china.huawei.com ([10.72.61.72]) with mapi id 14.01.0323.003; Thu, 10 May 2012 17:19:56 +0800 From: "Fuyu (Eleven)" To: Ted Lemon Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-secure-dhcpv6 Thread-Index: AQHNLAsVRkeC+DGqZUSiKnkXQXYkx5bCU4sg Date: Thu, 10 May 2012 09:19:56 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.4.119] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: DHC WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-secure-dhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 09:22:44 -0000 Hi all, I am in favor of advancing this draft. Thanks Yu -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= ed Lemon Sent: Monday, May 07, 2012 12:37 PM To: DHC WG Subject: [dhcwg] WGLC: draft-ietf-dhc-secure-dhcpv6 In the Paris meeting a show of hands indicated that the group favored bring= ing this document to last call. So this is the last call for this documen= t. If you are in favor of advancing it, and have read it, please say so. = If you think it needs work, please send text or suggestions. If you don= 't think it should advance, please say so. We will determine consensus on May 21. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From leo.liubing@huawei.com Thu May 10 20:23:33 2012 Return-Path: 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 33F0521F8539 for ; Thu, 10 May 2012 20:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.31 X-Spam-Level: X-Spam-Status: No, score=-2.31 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 wlQVXW3Z5lLh for ; Thu, 10 May 2012 20:23:31 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 36E0A21F852A for ; Thu, 10 May 2012 20:23:31 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGB04660; Thu, 10 May 2012 23:23:31 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 10 May 2012 20:21:13 -0700 Received: from SZXEML433-HUB.china.huawei.com (10.72.61.61) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 10 May 2012 20:21:19 -0700 Received: from SZXEML509-MBX.china.huawei.com ([10.82.67.37]) by szxeml433-hub.china.huawei.com ([10.72.61.61]) with mapi id 14.01.0323.003; Fri, 11 May 2012 11:21:13 +0800 From: "Liubing (Leo)" To: madi , DHC WG Thread-Topic: [dhcwg] Fw: WGLC: draft-ietf-dhc-secure-dhcpv6 Thread-Index: AQHNLM1zr2GwkkwOF0uE0iTeNdL0wpbD7Rkg Date: Fri, 11 May 2012 03:21:13 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45292C7194@szxeml509-mbx> References: <201205081148191100934@cnnic.cn> In-Reply-To: <201205081148191100934@cnnic.cn> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.4.84] Content-Type: multipart/alternative; boundary="_000_8AE0F17B87264D4CAC7DE0AA6C406F45292C7194szxeml509mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [dhcwg] Fw: WGLC: draft-ietf-dhc-secure-dhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 03:23:33 -0000 --_000_8AE0F17B87264D4CAC7DE0AA6C406F45292C7194szxeml509mbx_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 I also support this draft to move forward. The draft provides a practical approach to secure the DHCPv6 interaction wi= th using the mature CGA mechanisms. B.R. Bing From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of D= i Ma Sent: Tuesday, May 08, 2012 11:48 AM To: DHC WG Subject: [dhcwg] Fw: WGLC: draft-ietf-dhc-secure-dhcpv6 Considering DHCPv6 is somehow of big importance in the era of IPv6, CGA, as= a well-fashioned IPv6 address, is going to protect DHCPv6 away from variou= s attacks. Some efforts on the standardization of related techniques should= be made. I am in favor of advancing this document. ________________________________ Di Ma CNNIC Advanced Research Department ___________________________________________________ China Internet Network Information Center Tel: (8610)-58813216 Https://www.cnnic.cn Add: 4, South 4th Street, Zhongguancun Haidian District, Beijing P.R.China 100190 POB: Beijing 349, Branch 6 ____________________________________________________ From: Ted Lemon Date: 2012-05-07 12:37 To: DHC WG Subject: [dhcwg] WGLC: draft-ietf-dhc-secure-dhcpv6 In the Paris meeting a show of hands indicated that the group favored bring= ing this document to last call. So this is the last call for this documen= t. If you are in favor of advancing it, and have read it, please say so. = If you think it needs work, please send text or suggestions. If you don= 't think it should advance, please say so. We will determine consensus on May 21. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg --_000_8AE0F17B87264D4CAC7DE0AA6C406F45292C7194szxeml509mbx_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1

I also sup= port this draft to move forward.
The draft provides a practical approach to secure the DHCPv6 interaction wi= th using the mature CGA mechanisms.

B.R.
Bing

From: dhcwg-boun= ces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Di Ma
Sent: Tuesday, May 08, 2012 11:48 AM
To: DHC WG
Subject: [dhcwg] Fw: WGLC: draft-ietf-dhc-secure-dhcpv6

 

Considering DHC= Pv6 is somehow of big importance in the&= nbsp;era of IPv6, CGA, as a well-fashioned&nb= sp;IPv6 address, is going to protect DHCPv6&n= bsp;away from various attacks. Some efforts o= n the standardization of related techniques s= hould be made. 

I am in&nb= sp;favor of advancing this document.<= /p>

 

Di Ma

CNNIC = Advanced Research Department
___________________________________________________

China = Internet Network Information Center
Tel: (8610)-58813216
Https://www.cnnic.cn=

Add: 4= , South 4th Street, Zhongguancun
Haidian District, Beijing
P.R.China 100190

POB: Beijing 349, Branch 6
____________________________________________________

 

From:&nb= sp;Ted Lemon=

Date:&nb= sp;2012-05-07 12:37

To: = ;DHC WG

Subject:= =  [dhcwg] WGLC: draft-ietf-dhc-secure-dhcpv6

In the Par= is meeting a show of hands indicated tha= t the group favored bringing this document&nb= sp;to last call.   So this is the&n= bsp;last call for this document.   If&nb= sp;you are in favor of advancing it, and=  have read it, please say so.  &nbs= p;If you think it needs work, please sen= d text or suggestions.   If you don= 't think it should advance, please say s= o.

 

We will de= termine consensus on May 21.

 

____________________= ___________________________

dhcwg mailing&n= bsp;list

dhcwg@ietf.org<= /o:p>

https://www.ietf.org= /mailman/listinfo/dhcwg

--_000_8AE0F17B87264D4CAC7DE0AA6C406F45292C7194szxeml509mbx_-- From ichiroumakino@gmail.com Fri May 11 00:27:46 2012 Return-Path: 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 DD9AD21F8497; Fri, 11 May 2012 00:27:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.797 X-Spam-Level: X-Spam-Status: No, score=-2.797 tagged_above=-999 required=5 tests=[AWL=-0.098, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 g8+05ajpCm0O; Fri, 11 May 2012 00:27:46 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 904A821F847E; Fri, 11 May 2012 00:27:45 -0700 (PDT) Received: by wibhr2 with SMTP id hr2so1148223wib.13 for ; Fri, 11 May 2012 00:27:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=H+XQjcRqizkOD6Pbt6bbTfTFJ1sgSEzeQqoiWSLkJWY=; b=GGOPPgH//jypxBDj11EsPBR6aq8y1hto+pOnQrjQbqbTpxCYekM6KOYyP9nHRJB7Om Ap8PJLoxgTKynJpSMp3L2JS0W09F/YAQAXpk2E0ye+NQUQqnASFzb1wAgo87don8jGQx ojJ9J3wxiv1VuSWLfwtlL5a4K982OnnhaJ4YHReO6vbDNVJOTxvtHQyhGP9kaVR2DtS1 fE4H/KtZRn9JymBvdOt8Y1KNt70bJ2cL7L3sS34uDzzbJ8QG77vhmtwgWsjWWsI5DjrJ K7+phOxl+kaUTybGWf3LhdnR7w7PAFvcStlk4aDPWoYV0DTTPn3CzmxPduaVgBqYDyiu YLzg== Received: by 10.216.139.73 with SMTP id b51mr803060wej.72.1336721263312; Fri, 11 May 2012 00:27:43 -0700 (PDT) Received: from dhcp-lys02-vla252-10-147-117-91.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id ff9sm8793392wib.2.2012.05.11.00.27.41 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 11 May 2012 00:27:42 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <20120507032857.32055.91989.idtracker@ietfa.amsl.com> Date: Fri, 11 May 2012 09:27:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120507032857.32055.91989.idtracker@ietfa.amsl.com> To: dhc WG X-Mailer: Apple Mail (2.1257) Cc: v6ops WG Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 07:27:47 -0000 All, greatly appreciated if you could give this a once-over. it is meant to = fix the issues identified by the RFC6204 effort in v6ops, and be the = basis for 3315bis. cheers, Ole On May 7, 2012, at 5:28 , internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Dynamic Host Configuration = Working Group of the IETF. >=20 > Title : Issues with multiple stateful DHCPv6 options > Author(s) : Ole Troan > Bernie Volz > Filename : draft-ietf-dhc-dhcpv6-stateful-issues-00.txt > Pages : 8 > Date : 2012-05-06 >=20 > Dynamic Host Configuration Protocol for IPv6 (DHCPv6) was not = written > with the expectation that additional stateful DHCPv6 options would = be > developed. IPv6 Prefix Options for Dynamic Host Configuration > Protocol (DHCP) version 6 shoe-horned the new options for Prefix > Delegation into DHCPv6. Implementation experience of the CPE model > described in has shown multiple issues with the DHCPv6 protocol in > supporting multiple stateful options. >=20 >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-stateful-issues-= 00.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > = ftp://ftp.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-stateful-issues-0= 0.txt >=20 > The IETF datatracker page for this Internet-Draft is: > = https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-stateful-issues/ >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From iesg-secretary@ietf.org Fri May 11 12:30:01 2012 Return-Path: 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 F2C4221F8723; Fri, 11 May 2012 12:30:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.51 X-Spam-Level: X-Spam-Status: No, score=-102.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 JkdxL6-Sa9XA; Fri, 11 May 2012 12:30:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FE1621F8731; Fri, 11 May 2012 12:30:00 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120511193000.14696.69577.idtracker@ietfa.amsl.com> Date: Fri, 11 May 2012 12:30:00 -0700 Cc: dhc mailing list , dhc chair , RFC Editor Subject: [dhcwg] Document Action: 'Description of Cisco Systems' Subnet Allocation Option for DHCPv4' to Informational RFC (draft-ietf-dhc-subnet-alloc-13.txt) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 19:30:01 -0000 The IESG has approved the following document: - 'Description of Cisco Systems' Subnet Allocation Option for DHCPv4' (draft-ietf-dhc-subnet-alloc-13.txt) as Informational RFC This document is the product of the Dynamic Host Configuration Working Group. The IESG contact persons are Ralph Droms and Brian Haberman. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-dhc-subnet-alloc/ Technical Summary This document defines a new DHCP option which is passed between the DHCP Client and the DHCP Server to request dynamic allocation of a subnet, give specifications of subnet(s) allocated, and report usage statistics. This memo documents the current usage of the option in agreement with [RFC3942], which declares that any pre-existing usages of option numbers in the range 128 - 223 should be documented and the working group will try to officially assign those numbers to those options. Working Group Summary There was nothing controversial about this document. There was consensus in the working group to include the following text in the document: At the time when RFC 3942 came out, Cisco Systems had already deployed products which made use of option number 220. In RFC 3942, section 4, procedure 2, it is clearly stated, "Vendors that currently use one or more of the reclassified options have 6 months following this RFC's publication date to notify the DHC WG and IANA that they are using particular options numbers and agree to document that usage in an RFC." This procedure was immediately followed. It further states, "Vendors have 18 months from this RFC's publication date to start the documentation process by submitting an Internet-Draft." This procedure was also followed. For the purposes of clarity, it was thought important for the submitted draft to go through Working Group review. This process took quite a long time, with the document moving to "Last Call" multiple times. Since Cisco Systems already had deployed products, and thus wanted to avoid anything except for minor changes to the existing option definition, it was deemed best for the document to be Informational instead of Standard Track. This decision was made in cooperation with the Working Group and Work Group Chair at the time. Document Quality There is at least one existing implementation of this specification. It is not known if additional DHCP server implementations have or will implement this draft. Existing implementations are believed to be available today. Beyond what was performed with key members of the dhc WG no special reviews were performed or required. Personnel The document shepherd is John Brzozowski . The responsible Area Director is Ralph Droms . From phdgang@gmail.com Sat May 12 18:08:51 2012 Return-Path: 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 E7AA321F867F for ; Sat, 12 May 2012 18:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.879 X-Spam-Level: X-Spam-Status: No, score=-2.879 tagged_above=-999 required=5 tests=[AWL=0.720, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 exZGQqBwhqqF for ; Sat, 12 May 2012 18:08:51 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 375F721F866B for ; Sat, 12 May 2012 18:08:51 -0700 (PDT) Received: by wibhn6 with SMTP id hn6so1160262wib.13 for ; Sat, 12 May 2012 18:08:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rLB8yN95JLNLi0ANwTC/zUYz1yB2zHvvF5peTK1bzYw=; b=MvOIlyoHp/oQO6zUDXxX7WyNM7e7t2RhD7lG6K4jZncRNKtK5077S9gq1sF3ZwkKMQ Dl6s7cri0p3VPxzu3vK0Dbwpl4KUj2cucaRsBOyyhd+C79TjeiauSREaPYJ7MEsSvLid jHBeZ3EnnloxueBD5FGzXacAhf1cC7xjtr68F9SwJ6SlvoZpSE/v7dce9u5QNGe7CtLD /1DJbAh2i7W7NnQ+jRTCNcuj6Jpccj+TXvBn32YNZb7LgNUSL+ZYrGJ/NXXQVqfLvoFi O0+jQ4Jr+zgPh2ET7Gt5maC2c1qQiWIEdx/FdG78fMMtHGQypuDroyNsiynshS9lwe5l +yPg== MIME-Version: 1.0 Received: by 10.180.88.199 with SMTP id bi7mr7768855wib.12.1336871330277; Sat, 12 May 2012 18:08:50 -0700 (PDT) Received: by 10.180.106.38 with HTTP; Sat, 12 May 2012 18:08:50 -0700 (PDT) In-Reply-To: References: Date: Sun, 13 May 2012 09:08:50 +0800 Message-ID: From: GangChen To: Ted Lemon Content-Type: text/plain; charset=ISO-8859-1 Cc: DHC WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-secure-dhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 May 2012 01:08:52 -0000 I think the draft is in a good shape. Support to move forward Many thanks Gang 2012/5/7, Ted Lemon : > In the Paris meeting a show of hands indicated that the group favored > bringing this document to last call. So this is the last call for this > document. If you are in favor of advancing it, and have read it, please > say so. If you think it needs work, please send text or suggestions. If > you don't think it should advance, please say so. > > We will determine consensus on May 21. > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > From wwwrun@rfc-editor.org Tue May 15 15:20:36 2012 Return-Path: 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 6CEF321F8759; Tue, 15 May 2012 15:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.099 X-Spam-Level: X-Spam-Status: No, score=-102.099 tagged_above=-999 required=5 tests=[AWL=-0.099, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 SHrOfvSAZpA4; Tue, 15 May 2012 15:20:36 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id E18F021F8758; Tue, 15 May 2012 15:20:35 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id BDE7FB1E002; Tue, 15 May 2012 15:17:55 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20120515221755.BDE7FB1E002@rfc-editor.org> Date: Tue, 15 May 2012 15:17:55 -0700 (PDT) Cc: dhcwg@ietf.org, rfc-editor@rfc-editor.org Subject: [dhcwg] RFC 6603 on Prefix Exclude Option for DHCPv6-based Prefix Delegation X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 22:20:36 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6603 Title: Prefix Exclude Option for DHCPv6-based Prefix Delegation Author: J. Korhonen, Ed., T. Savolainen, S. Krishnan, O. Troan Status: Standards Track Stream: IETF Date: May 2012 Mailbox: jouni.nospam@gmail.com, teemu.savolainen@nokia.com, suresh.krishnan@ericsson.com, ot@cisco.com Pages: 10 Characters: 19485 Updates: RFC3633 I-D Tag: draft-ietf-dhc-pd-exclude-04.txt URL: http://www.rfc-editor.org/rfc/rfc6603.txt This specification defines an optional mechanism to allow exclusion of one specific prefix from a delegated prefix set when using DHCPv6-based prefix delegation. The new mechanism updates RFC 3633. [STANDARDS-TRACK] This document is a product of the Dynamic Host Configuration Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From internet-drafts@ietf.org Fri May 18 09:17:52 2012 Return-Path: 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 B5B5D21F86B1; Fri, 18 May 2012 09:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 bYbQ0LGw1OKA; Fri, 18 May 2012 09:17:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1654C21F865A; Fri, 18 May 2012 09:17:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120518161752.11942.18007.idtracker@ietfa.amsl.com> Date: Fri, 18 May 2012 09:17:52 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv4-over-ipv6-03.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 16:17:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Dynamic Host Configuration Working Gr= oup of the IETF. Title : DHCPv4 over IPv6 Transport Author(s) : Yong Cui Peng Wu Jianping Wu Ted Lemon Filename : draft-ietf-dhc-dhcpv4-over-ipv6-03.txt Pages : 12 Date : 2012-05-18 In IPv6 networks, there remains a need to provide IPv4 service for some residual devices. This document describes a mechanism for allocating IPv4 addresses to such devices, using DHCPv4 with an IPv6 transport. It is done by putting a special relay agent function (Client Relay Agent) on the client side, as well as extending the behavior of the server; in the case where DHCP server only supports IPv4 transport, a relay agent is extended to support IPv6 transport (IPv6-Transport Relay Agent) and relay DHCP traffic for the server, with a new Relay Agent Information sub-option added to carry the IPv6 address of the Client Relay Agent. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv4-over-ipv6-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv4-over-ipv6-03.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv4-over-ipv6/ From fernando.gont.netbook.win@gmail.com Fri May 18 17:07:01 2012 Return-Path: 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 5A8F721F856C for ; Fri, 18 May 2012 17:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 UipH8UbiFk6d for ; Fri, 18 May 2012 17:07:00 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id B32E221F859B for ; Fri, 18 May 2012 17:07:00 -0700 (PDT) Received: by yhq56 with SMTP id 56so4050263yhq.31 for ; Fri, 18 May 2012 17:07:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:x-forwarded-message-id :content-type:content-transfer-encoding; bh=pKJIQr/I9Tcq+k0beG4y+c82CUTKmaIrPOqfxW9+xeI=; b=UBoaGF09qo1PLxrG8ubClVXd3DV5g1l4+kJlWuJe6yyODtB6f0tr06GFhFvuKI3c9O SKcTGt05ZfZLIhMCpFMocC/G3/ixXZYdYvwOTUSRteLedZvEeCFKpcwuhRqJisECCtpo Tb7qJZzUoqZH27FoR1soMylCahVx+a4quW71kDn3mB4w3RZBpBYaH3+0cnATNlX2gURl 7pia6TJdJ2DrnwfhMkiXcQc4NS1e1gRZuL1h/FsLZoFP0fjKQ4ljZxfamsU6fqsH1kmK 9W6Wmz+FZExXI/RDL95Qgf2aaJclu9usAw4KiEXemsv6mckEOCwCzc8d35kHmOzxkApw T6uw== Received: by 10.236.146.72 with SMTP id q48mr3551290yhj.98.1337386020279; Fri, 18 May 2012 17:07:00 -0700 (PDT) Received: from [192.168.1.114] ([190.190.97.123]) by mx.google.com with ESMTPS id f61sm42891781yhg.14.2012.05.18.17.06.56 (version=SSLv3 cipher=OTHER); Fri, 18 May 2012 17:06:58 -0700 (PDT) Sender: Fernando Gont Message-ID: <4FB6DC64.9060908@gont.com.ar> Date: Fri, 18 May 2012 20:33:56 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: dhcwg@ietf.org References: <20120518052610.7838.76832.idtracker@ietfa.amsl.com> In-Reply-To: <20120518052610.7838.76832.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5pre X-Forwarded-Message-Id: <20120518052610.7838.76832.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [dhcwg] New IETF I-D: draft-gont-opsec-dhcpv6-shield-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 May 2012 00:07:01 -0000 Folks, We have published a new IETF I-D entitled: "DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers". It is analogous to the RA-Guard (RFC 6105) mechanism currently employed for mitigating RA-based attacks. The I-D is available at: I'm not sure in which wg I'd be pursuing this effort (v6ops, opsec, or dhcwg). If there's interest in this wg, it could be done here. However, in any case discussion of this document within dhcwg would be welcome. Thanks! Best regards, Fernando -------- Original Message -------- Subject: New Version Notification for draft-gont-opsec-dhcpv6-shield-00.txt Date: Thu, 17 May 2012 22:26:10 -0700 From: internet-drafts@ietf.org To: fgont@si6networks.com A new version of I-D, draft-gont-opsec-dhcpv6-shield-00.txt has been successfully submitted by Fernando Gont and posted to the IETF repository. Filename: draft-gont-opsec-dhcpv6-shield Revision: 00 Title: DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers Creation date: 2012-05-18 WG ID: Individual Submission Number of pages: 12 Abstract: This document specifies a mechanism for protecting hosts connected to a broadcast network against rogue DHCPv6 servers. The aforementioned mechanism is based on DHCPv6 packet-filtering at the layer-2 device on which the packets are received. The aforementioned mechanism has been widely deployed in IPv4 networks ("DHCP snooping"), and hence it is desirable that similar functionality be provided for IPv6 networks. The IETF Secretariat From shemant@cisco.com Mon May 21 07:05:24 2012 Return-Path: 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 300F421F859B; Mon, 21 May 2012 07:05:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 9ISYJGPtCTTH; Mon, 21 May 2012 07:05:23 -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 7393A21F8597; Mon, 21 May 2012 07:05:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=624; q=dns/txt; s=iport; t=1337609123; x=1338818723; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=o6t5/gpuvixE6wcXZ/qPIZ2hDn44gjJ8N38as7dfpdY=; b=K2qFbhF3+PQVqRyAU3oYmud8CJck25m/E8qW8rHBTWGIDMlhxwfPvzT+ ENmLUDdIKTAuosB5mKsnT7m39Zn7mFC6yrF2khdb1mnFFBFW4YIeYQwu8 YYTycbGXIyAwdy5MnJsOT+VmMToZOusGTQY9YPTlI38jUuD/gVD4+eu3y 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAD5Luk+tJXG//2dsb2JhbABEtAKBB4IVAQEBBBIBHUkMBAIBCBEEAQELBhcBBgFFCQgBAQQBEggah2wLny+faYsFhGtiA4gPM41ojH2BZIMH X-IronPort-AV: E=Sophos;i="4.75,631,1330905600"; d="scan'208";a="85156200" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-4.cisco.com with ESMTP; 21 May 2012 14:05:23 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q4LE5MDm028940; Mon, 21 May 2012 14:05:22 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 21 May 2012 09:05:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 21 May 2012 09:05:21 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C304B6379D@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] 6204bis draft 09 -http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-09 Thread-Index: Ac03JnQC/fsm1WOcQp+rHjo1zoByRwANAgmA References: <4FB86EF8.9030101@bogus.com> From: "Hemant Singh (shemant)" To: =?iso-8859-1?Q?Ole_Tr=F8an?= , "Joel jaeggli" X-OriginalArrivalTime: 21 May 2012 14:05:22.0930 (UTC) FILETIME=[C3732520:01CD375A] Cc: dhcwg , IPv6 Ops WG Subject: Re: [dhcwg] [v6ops] 6204bis draft 09 -http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-09 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 14:05:24 -0000 -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of Ole Tr=F8an Sent: Monday, May 21, 2012 3:50 AM To: Joel jaeggli Cc: IPv6 Ops WG Subject: Re: [v6ops] 6204bis draft 09 = -http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-09 >I-D.ietf-dhc-dhcpv6-stateful-issues should be a normative reference. When do we think the above document can be sent to the IESG by the DHC = WG? Rfc6204bis is sensitive to any delays for publication if a = normative reference does not become an RFC around the time of = publication for rfc6204bis. Thanks, Hemant From volz@cisco.com Mon May 21 07:45:13 2012 Return-Path: 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 8CE3921F84DF; Mon, 21 May 2012 07:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 U3PonQG4KDKC; Mon, 21 May 2012 07:45:13 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id D569421F84D8; Mon, 21 May 2012 07:45:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=1348; q=dns/txt; s=iport; t=1337611513; x=1338821113; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=a/SxUCNSqox7GiUvQaLlMc9qVWpwEMjyDwoXhWv+50s=; b=Q+hzcXDqr/CYLv4RS43l73qYr4xLtEIYPap+/x0BVE4Rw+5rCStf2x64 L/7hcEaEceaWOguNLhlDBL18uVaot3EEby5H5r88uODc8jaCNKEC3xfPx Y74K+t6KFnqm4TWiVOEWoeLUASSzSlpNiqiVNAaWsiFoWJQbc6zmBQbaS Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAKBTuk+tJXG+/2dsb2JhbABEtAKBB4IVAQEBBAEBAQ8BHT4LDAQCAQgRBAEBCwYXAQYBJh8JCAEBBBMIGodsC58hn2eLBYIvgjxiA4gPM41ojH2BZIMH X-IronPort-AV: E=Sophos;i="4.75,631,1330905600"; d="scan'208";a="85108428" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-6.cisco.com with ESMTP; 21 May 2012 14:45:11 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q4LEjBRv017819; Mon, 21 May 2012 14:45:11 GMT Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 21 May 2012 09:45:10 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 21 May 2012 09:44:59 -0500 Message-ID: In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C304B6379D@XMB-RCD-109.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] 6204bis draft 09-http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-09 Thread-Index: Ac03JnQC/fsm1WOcQp+rHjo1zoByRwANAgmAAAFlqqA= References: <4FB86EF8.9030101@bogus.com> <5B6B2B64C9FE2A489045EEEADDAFF2C304B6379D@XMB-RCD-109.cisco.com> From: "Bernie Volz (volz)" To: X-OriginalArrivalTime: 21 May 2012 14:45:10.0746 (UTC) FILETIME=[52B2F3A0:01CD3760] Cc: Joel jaeggli , IPv6 Ops WG Subject: Re: [dhcwg] [v6ops] 6204bis draft 09-http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-09 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 14:45:13 -0000 Can we request that the DHC WG chairs to start a DHC WG last-call on the = document? There has been no real discussion of it so far on the mailing = list; perhaps this is one way to trigger that discussion? It would be = nice to move this document along!! - Bernie -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of Hemant Singh (shemant) Sent: Monday, May 21, 2012 10:05 AM To: Ole Tr=F8an; Joel jaeggli Cc: dhcwg; IPv6 Ops WG Subject: Re: [v6ops] 6204bis draft = 09-http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-09 -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of Ole Tr=F8an Sent: Monday, May 21, 2012 3:50 AM To: Joel jaeggli Cc: IPv6 Ops WG Subject: Re: [v6ops] 6204bis draft 09 = -http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-09 >I-D.ietf-dhc-dhcpv6-stateful-issues should be a normative reference. When do we think the above document can be sent to the IESG by the DHC = WG? Rfc6204bis is sensitive to any delays for publication if a = normative reference does not become an RFC around the time of = publication for rfc6204bis. Thanks, Hemant _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From shemant@cisco.com Mon May 21 12:53:26 2012 Return-Path: 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 532C921F859F; Mon, 21 May 2012 12:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.149 X-Spam-Level: X-Spam-Status: No, score=-10.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 OTn--Evnb-dy; Mon, 21 May 2012 12:53:25 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 7B19621F848E; Mon, 21 May 2012 12:53:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=1658; q=dns/txt; s=iport; t=1337630005; x=1338839605; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=er4TO0/8UxKOaGInDQk1UvEGPenA/2J2Bo5KYqcPrFs=; b=fFXg3H2jAyxEy9tX2Rtniu529OUV6uoiiCwTU6yIuc17lMIJYJ4UNrXH owPGIf5HPgE1NyGNSE2TdT36jFGdBF88rKDBU8dyrZKjlFqC9hbDmmK+V f3O7CJdbCnpUIEAX5p6AB4a+ejczOqADYZRff2kf0I7h6Gav3Sf0fe/ne U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIicuk+tJV2a/2dsb2JhbABEtBqBB4IVAQEBBAEBAQ8BHT4LDAQCAQgRBAEBCwYXAQYBJh8JCAEBBAESCBqHbAufEp9+iwWEWmIDiA8zjWiMfYFkgwc X-IronPort-AV: E=Sophos;i="4.75,632,1330905600"; d="scan'208";a="85201277" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-2.cisco.com with ESMTP; 21 May 2012 19:53:25 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q4LJrPQ5031580; Mon, 21 May 2012 19:53:25 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 21 May 2012 14:53:24 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 21 May 2012 14:53:23 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C304B6392D@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] 6204bis draft 09-http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-09 Thread-Index: Ac03JnQC/fsm1WOcQp+rHjo1zoByRwANAgmAAAFlqqAACtJPMA== References: <4FB86EF8.9030101@bogus.com> <5B6B2B64C9FE2A489045EEEADDAFF2C304B6379D@XMB-RCD-109.cisco.com> From: "Hemant Singh (shemant)" To: "Bernie Volz (volz)" , X-OriginalArrivalTime: 21 May 2012 19:53:24.0969 (UTC) FILETIME=[621D6D90:01CD378B] Cc: Joel jaeggli , IPv6 Ops WG Subject: Re: [dhcwg] [v6ops] 6204bis draft 09-http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-09 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 19:53:26 -0000 Thanks, Bernie! Hemant -----Original Message----- From: Bernie Volz (volz)=20 Sent: Monday, May 21, 2012 10:45 AM To: dhcwg@ietf.org Cc: IPv6 Ops WG; Hemant Singh (shemant); Ole Tr=F8an; Joel jaeggli Subject: RE: [v6ops] 6204bis draft = 09-http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-09 Can we request that the DHC WG chairs to start a DHC WG last-call on the = document? There has been no real discussion of it so far on the mailing = list; perhaps this is one way to trigger that discussion? It would be = nice to move this document along!! - Bernie -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of Hemant Singh (shemant) Sent: Monday, May 21, 2012 10:05 AM To: Ole Tr=F8an; Joel jaeggli Cc: dhcwg; IPv6 Ops WG Subject: Re: [v6ops] 6204bis draft = 09-http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-09 -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of Ole Tr=F8an Sent: Monday, May 21, 2012 3:50 AM To: Joel jaeggli Cc: IPv6 Ops WG Subject: Re: [v6ops] 6204bis draft 09 = -http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-09 >I-D.ietf-dhc-dhcpv6-stateful-issues should be a normative reference. When do we think the above document can be sent to the IESG by the DHC = WG? Rfc6204bis is sensitive to any delays for publication if a = normative reference does not become an RFC around the time of = publication for rfc6204bis. Thanks, Hemant _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From internet-drafts@ietf.org Tue May 22 18:01:44 2012 Return-Path: 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 3EA3521F86B7; Tue, 22 May 2012 18:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.389 X-Spam-Level: X-Spam-Status: No, score=-102.389 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 FCDo3ZfhHtbW; Tue, 22 May 2012 18:01:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC53821F85C3; Tue, 22 May 2012 18:01:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120523010143.18563.38922.idtracker@ietfa.amsl.com> Date: Tue, 22 May 2012 18:01:43 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-host-gen-id-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 01:01:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Dynamic Host Configuration Working Gr= oup of the IETF. Title : Prefix Assignment in DHCPv6 Author(s) : Sheng Jiang Frank Xia Behcet Sarikaya Filename : draft-ietf-dhc-host-gen-id-02.txt Pages : 10 Date : 2012-05-22 This document introduce a procedure for configuring hosts' IPv6 address which the prefix is assigned from a DHCPv6 server through DHCPv6 protocol while the interface identifiers are independently generated by the hosts. The method is applicable to Cryptographically Generated Addresses (CGA), and other IPv6 addresses with host-generated interface identifiers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-host-gen-id-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dhc-host-gen-id-02.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-host-gen-id/ From ghalwasi@cisco.com Thu May 24 08:03:34 2012 Return-Path: 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 8891321F8675 for ; Thu, 24 May 2012 08:03:34 -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 1MRDzlgBXskU for ; Thu, 24 May 2012 08:03:32 -0700 (PDT) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id 5802E21F8649 for ; Thu, 24 May 2012 08:03:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ghalwasi@cisco.com; l=9779; q=dns/txt; s=iport; t=1337871808; x=1339081408; h=mime-version:subject:date:message-id:from:to; bh=cYOZhoe2UtqRSlk7wDXYraopHLaEoTwX3SOpbsoSGiY=; b=G+bOLb7V4mTiMRMK3W99EmhRo8WKbk6dynsr1QOhC5l8uHtvCTw4F5j7 KHMn2fjM816IzRpbGDnX2iQ8T36LRQH+5XOx4SjmXax4xmoioRXztHg3m LFuceCLpT//p47Yk0GQkoXG3GUpNCT9YqD+eO9uPLL8SD6mMxqhTXtqWu 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFAFFMvk9Io8UY/2dsb2JhbABDgkWoTQGKPIIXAQQSAQkRA1sBKgYYB1cBBAsQEweHawuaD4EooAKPP2ADiD2Naox9gWSCcg X-IronPort-AV: E=Sophos;i="4.75,651,1330905600"; d="scan'208,217";a="12938185" Received: from vla196-nat.cisco.com (HELO bgl-core-1.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 24 May 2012 15:03:26 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q4OF3Qqq018377 for ; Thu, 24 May 2012 15:03:26 GMT Received: from xmb-bgl-41e.cisco.com ([72.163.129.220]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 24 May 2012 20:33:26 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD39BE.5E8250D2" Date: Thu, 24 May 2012 20:33:25 +0530 Message-ID: <3CF88B99A9ED504197498BC6F6F04B81069F01D7@XMB-BGL-41E.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-troan-dhc-dhcpv6-stateful-issues-00 Thread-Index: Ac05uKdEL2fp8FLMS7ymS5aexC6oDg== From: "Gaurav Halwasia (ghalwasi)" To: X-OriginalArrivalTime: 24 May 2012 15:03:26.0134 (UTC) FILETIME=[5ED72560:01CD39BE] Subject: [dhcwg] Comments on draft-troan-dhc-dhcpv6-stateful-issues-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 15:03:34 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD39BE.5E8250D2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have read this informational draft and I have couple of comments so far. =20 1.)Section 3.1 Replace Section 17.1.3 : (existing errata) =20 =20 The client MUST ignore any Advertise message that includes a Status Code option containing the value NoAddrsAvail, with the exception that the client MAY display the associated status message to the user. =20 With: =20 =20 The client MUST ignore any IAs in an Advertise message that includes a Status Code option containing the value NoAddrsAvail, with the exception that the client MAY display the associated status message to the user. An Advertise message without any IA options MUST be ignored. =20 Is this only applicable to IA_NA.? I guess in case client sends SOLICIT with both IA_NA and IA_PD. Then in that case I guess we should mention "NoPrefixAvail" as well. =20 2.) Section 3.6 Proposed solution: the client should keep a single session with the server. The client should continue with the IA_ options received, while continuing to request the other IA options in subsequent messages to the server. That means continue to include the empty unanswered IAs in subsequent Renew and Rebind messages. =20 I believe, it is possible that a particular server is willing to offer only a subset of IA_'s which has been requested. In that case, what's the use of including the other IA_ in the subsequent renew/rebind. As in this case server will anyway only renew only one IA_. ? Are we suggesting that a client at any given point of time should only be talking to one server after the advertise is accepted. =20 =20 ------_=_NextPart_001_01CD39BE.5E8250D2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have read this = informational draft and I have couple of comments so = far.

 

1.)Section = 3.1

   =
Replace Section 17.1.3: (existing =
errata)
 
 
      The client =
MUST ignore any Advertise message that includes a =
Status
      Code option =
containing the value NoAddrsAvail, with the =
exception
      that the =
client MAY display the associated status message to =
the
      =
user.
 
   With:
 
 
      The client =
MUST ignore any IAs in an Advertise message that
      includes a =
Status Code option containing the value =
NoAddrsAvail,
      with the =
exception that the client MAY display the =
associated
      status message =
to the user. An Advertise message without any IA
      options MUST =
be ignored.

 

Is this only applicable to =
IA_NA.? I guess in case client sends SOLICIT with both IA_NA and IA_PD. =
Then in that case I guess we should mention “NoPrefixAvail” =
as well.
 
2.) Section =
3.6
   =
Proposed solution: the client should keep a single session with =
the
   =
server.  The client should continue with the IA_ options =
received,
   =
while continuing to request the other IA options in =
subsequent
   =
messages to the server.  That means continue to include the =
empty
   =
unanswered IAs in subsequent Renew and Rebind =
messages.
 
I believe, it =
is possible that a particular server is willing to offer only a subset =
of IA_’s which has been requested. In that case, what’s the =
use of including the other IA_ in the subsequent renew/rebind. As in =
this case server will anyway only renew only one IA_. ? Are we =
suggesting that a client at any given point of time should only be =
talking to one server after the advertise is =
accepted.
 
 
------_=_NextPart_001_01CD39BE.5E8250D2-- From volz@cisco.com Thu May 24 12:29:56 2012 Return-Path: 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 9ACCC21F84CD for ; Thu, 24 May 2012 12:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.298 X-Spam-Level: X-Spam-Status: No, score=-10.298 tagged_above=-999 required=5 tests=[AWL=0.300, 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 K5n0dJiSDTis for ; Thu, 24 May 2012 12:29:54 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 4D12121F848E for ; Thu, 24 May 2012 12:29:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16298; q=dns/txt; s=iport; t=1337887794; x=1339097394; h=mime-version:subject:date:message-id:from:to; bh=ZV8rUYwefiKMKtpkJ8Ka24zRsGHSMlXSKJW3iTJIbEY=; b=DMl6UGjatCwucTja2g5eiMGJdYVKv+yZj+xg4MMdxP7jIjiVps1E3cyG LveM9gGgX6IGSnBYXzPMEe4KFygckIVNUmzT6AdsPvZDe9dhTfawwlf/w 9JWEEJ05N8j1oYDskZ5IT+V6ORTrNknqYJod5EOsfJ6m/ASycgHUQEsIO Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFAPWKvk+tJXG9/2dsb2JhbABDgkWoUwGJTIEHghUBAQEEEgEJEQNbAQgRBAEBCwYXAQdFCQkBBAESCBMHh2sLm0+gBYp/hEBgA4g/jWiMfYFkgwg X-IronPort-AV: E=Sophos;i="4.75,652,1330905600"; d="scan'208,217";a="83435047" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-9.cisco.com with ESMTP; 24 May 2012 19:29:53 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q4OJTr7U021672 for ; Thu, 24 May 2012 19:29:53 GMT Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 24 May 2012 14:29:53 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD39E3.980CF93D" Date: Thu, 24 May 2012 14:29:52 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-troan-dhc-dhcpv6-stateful-issues-00 thread-index: Ac05uKdEL2fp8FLMS7ymS5aexC6oDgAKig9Q From: "Bernie Volz (volz)" To: "Gaurav Halwasia (ghalwasi)" , X-OriginalArrivalTime: 24 May 2012 19:29:53.0258 (UTC) FILETIME=[97E8ACA0:01CD39E3] Subject: Re: [dhcwg] Comments on draft-troan-dhc-dhcpv6-stateful-issues-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 19:29:56 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD39E3.980CF93D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi and thanks for reading and commenting! =20 Comments below (BV>). =20 - Bernie =20 From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Gaurav Halwasia (ghalwasi) Sent: Thursday, May 24, 2012 11:03 AM To: dhcwg@ietf.org Subject: [dhcwg] Comments on draft-troan-dhc-dhcpv6-stateful-issues-00 =20 I have read this informational draft and I have couple of comments so far. =20 1.)Section 3.1 Replace Section 17.1.3 : (existing errata) =20 =20 The client MUST ignore any Advertise message that includes a Status Code option containing the value NoAddrsAvail, with the exception that the client MAY display the associated status message to the user. =20 With: =20 =20 The client MUST ignore any IAs in an Advertise message that includes a Status Code option containing the value NoAddrsAvail, with the exception that the client MAY display the associated status message to the user. An Advertise message without any IA options MUST be ignored. =20 Is this only applicable to IA_NA.? I guess in case client sends SOLICIT with both IA_NA and IA_PD. Then in that case I guess we should mention "NoPrefixAvail" as well. =20 BV> It is applicable to IA_NA and IA_TA as those are the cases that end up with the Status Code option of NoAddsAvailable in the "main" part of the message - not in each IA_NA/IA_TA. (IA_PD puts the NoPrefixAvail Status Code option in the IA_PD itself. This is what we wish had been specified for IA_NA/IA_TA but was not.) =20 2.) Section 3.6 Proposed solution: the client should keep a single session with the server. The client should continue with the IA_ options received, while continuing to request the other IA options in subsequent messages to the server. That means continue to include the empty unanswered IAs in subsequent Renew and Rebind messages. =20 I believe, it is possible that a particular server is willing to offer only a subset of IA_'s which has been requested. In that case, what's the use of including the other IA_ in the subsequent renew/rebind. As in this case server will anyway only renew only one IA_. ? Are we suggesting that a client at any given point of time should only be talking to one server after the advertise is accepted. =20 BV> What harm is there in continuing to include this in the subsequent operations? If the server's policy prohibits returning addresses or delegated prefixes for these other IA types, there is no harm. The main assumption is that clients are in a single administrative domain and thus talking to another server will be unlikely to help (except of course in the case of misconfiguration, but better that the issue is detected early and dealt with). =20 - Bernie ------_=_NextPart_001_01CD39E3.980CF93D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi and thanks for reading and = commenting!

 

Comments below = (BV>).

 

-          = Bernie

 

From:= = dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of = Gaurav Halwasia (ghalwasi)
Sent: Thursday, May 24, 2012 = 11:03 AM
To: dhcwg@ietf.org
Subject: [dhcwg] = Comments on = draft-troan-dhc-dhcpv6-stateful-issues-00

 

I have read this = informational draft and I have couple of comments so = far.

 

1.)Section = 3.1

   =
Replace Section 17.1.3: (existing =
errata)
 
 
      The client =
MUST ignore any Advertise message that includes a =
Status
      Code option =
containing the value NoAddrsAvail, with the =
exception
      that the =
client MAY display the associated status message to =
the
      =
user.
 
   With:
 
 
      The client =
MUST ignore any IAs in an Advertise message that
      includes a =
Status Code option containing the value =
NoAddrsAvail,
      with the =
exception that the client MAY display the =
associated
      status message =
to the user. An Advertise message without any IA
      options MUST =
be ignored.

 

Is this only applicable to =
IA_NA.? I guess in case client sends SOLICIT with both IA_NA and IA_PD. =
Then in that case I guess we should mention “NoPrefixAvail” =
as well.
 
BV> It is applicable to IA_NA and IA_TA as those are the cases =
that end up with the Status Code option of NoAddsAvailable in the =
“main” part of the message – not in each IA_NA/IA_TA. =
(IA_PD puts the NoPrefixAvail Status Code option in the IA_PD itself. =
This is what we wish had been specified for IA_NA/IA_TA but was =
not.)
 
2.) Section =
3.6
   =
Proposed solution: the client should keep a single session with =
the
   =
server.  The client should continue with the IA_ options =
received,
   =
while continuing to request the other IA options in =
subsequent
   =
messages to the server.  That means continue to include the =
empty
   =
unanswered IAs in subsequent Renew and Rebind =
messages.
 
I believe, it =
is possible that a particular server is willing to offer only a subset =
of IA_’s which has been requested. In that case, what’s the =
use of including the other IA_ in the subsequent renew/rebind. As in =
this case server will anyway only renew only one IA_. ? Are we =
suggesting that a client at any given point of time should only be =
talking to one server after the advertise is =
accepted.
 
BV> What harm is there in continuing to include this in the =
subsequent operations? If the server’s policy prohibits returning =
addresses or delegated prefixes for these other IA types, there is no =
harm. The main assumption is that clients are in a single administrative =
domain and thus talking to another server will be unlikely to help =
(except of course in the case of misconfiguration, but better that the =
issue is detected early and dealt =
with).
 
-          =
Bernie
------_=_NextPart_001_01CD39E3.980CF93D-- From pradeepar@gmail.com Thu May 24 11:40:33 2012 Return-Path: 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 2755621F84A1 for ; Thu, 24 May 2012 11:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.551 X-Spam-Level: X-Spam-Status: No, score=-3.551 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 fvszO5fHmaVz for ; Thu, 24 May 2012 11:40:32 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id AD1A621F847E for ; Thu, 24 May 2012 11:40:32 -0700 (PDT) Received: by dacx6 with SMTP id x6so115089dac.31 for ; Thu, 24 May 2012 11:40:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=zTq4AXSKCLRi8Jnoj0EZZvHyiYNWsGH8DWvH9D3mCt8=; b=vUJp6U5WRtrttazrzFoYW9RchkXbaYE+7A8He1QHZ9zRFc7ifs49cBNtuGVpDV4jJN 13NuWaVzp3K2vk875BQGXKQLVB9dIlHCdDdQq6i4PCwA3HTReGiXpG/hD7iC5XnpnVOS 74eT7Y2vDcYwkaFKTJjva5n7iMltY3XCjKXsZIGFfJJtLarEk5VXvCvVT6Kqa20BU5AU TK6Z3/Rnum7fjewxGtweZ+ZlxWVsgv0kB50mh1M02dxI2fBovTWOdtaBPuJC9YIGJWfw CYp6hy+VTAKZoRAe/N60D0Xyu0MC8gF17DeLlHmPJObd6Zba/0FtLAVTTQyhwCuIld4T dYQw== MIME-Version: 1.0 Received: by 10.68.220.97 with SMTP id pv1mr23475500pbc.158.1337884832274; Thu, 24 May 2012 11:40:32 -0700 (PDT) Received: by 10.68.25.37 with HTTP; Thu, 24 May 2012 11:40:32 -0700 (PDT) Date: Fri, 25 May 2012 00:10:32 +0530 Message-ID: From: a r pradeep To: dhcwg@ietf.org Content-Type: multipart/alternative; boundary=e89a8ff2536e2d981f04c0cc969b X-Mailman-Approved-At: Thu, 24 May 2012 14:29:58 -0700 Subject: [dhcwg] Question on DHCPv6 / RFC3315 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 18:40:33 -0000 --e89a8ff2536e2d981f04c0cc969b Content-Type: text/plain; charset=ISO-8859-1 Hello All Had a question on RFC 3315, Section 18.1.2 Creation and Transmission of Confirm messages When a client changes its configuration from dhcpv6 enabled to static, is this considered as moving to new link and is the client required to send out a Confirm message ? Thanks pradeep --e89a8ff2536e2d981f04c0cc969b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello All
=A0
Had a question on RFC 3315, Section 18.1.2 Creation and= Transmission of Confirm messages
=A0
When a client changes its confi= guration from dhcpv6 enabled to static, is this considered as moving to new= link and is the client required to send out a Confirm message ?
=A0
Thanks
pradeep --e89a8ff2536e2d981f04c0cc969b-- From akostur@incognito.com Thu May 24 18:20:56 2012 Return-Path: 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 6D75211E8080 for ; Thu, 24 May 2012 18:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.429 X-Spam-Level: X-Spam-Status: No, score=-4.429 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, RCVD_IN_DNSWL_MED=-4] 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 zl4r4btay0YZ for ; Thu, 24 May 2012 18:20:55 -0700 (PDT) Received: from na3sys010aog103.obsmtp.com (na3sys010aog103.obsmtp.com [74.125.245.74]) by ietfa.amsl.com (Postfix) with SMTP id 2986711E8085 for ; Thu, 24 May 2012 18:20:54 -0700 (PDT) Received: from mail-lb0-f171.google.com ([209.85.217.171]) (using TLSv1) by na3sys010aob103.postini.com ([74.125.244.12]) with SMTP ID DSNKT77edtPYM98sEsqFoCj08VN1okxPq+xY@postini.com; Thu, 24 May 2012 18:20:55 PDT Received: by lbom4 with SMTP id m4so395421lbo.2 for ; Thu, 24 May 2012 18:20:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=aYGELT55nDgGkmCtpSoYVk792YoK1yQ92bA+O9dt9DY=; b=RxSZRLLNDhyOyUtyqxA4Di5mZPypKRvncK4YegWz5aGLsS7X0O3rcYuF9Ym3RVuXXz nNMYaiZuzEuauf2whUnrHsdohF1rwU25PlKutYiy3vF6Jq8IUenx6b/kSw19McokiDOU omdw3v++cYwo0uvGT49uGI2zStZrI+/PrMUn9s5SrvHvJFkk5il0m5egyOKBqXEQo3vk jPqwiwFN5IpLK9QZoooHbUEr9ALuq4vs7Gxms+Uu8P5oDIBfEEm7Tx1HQ+sryM4d+Ejj nnFIi2YdREluhjLGoUTtqSNwjJ1CRUzEiqzp1SrpxIHtcEwSBjUrP7B7Xv36HKOxa1aK I4Aw== MIME-Version: 1.0 Received: by 10.112.54.40 with SMTP id g8mr695934lbp.1.1337908852534; Thu, 24 May 2012 18:20:52 -0700 (PDT) Received: by 10.112.40.228 with HTTP; Thu, 24 May 2012 18:20:52 -0700 (PDT) In-Reply-To: References: Date: Thu, 24 May 2012 18:20:52 -0700 Message-ID: From: Andre Kostur To: a r pradeep Content-Type: multipart/alternative; boundary=bcaec5555556e5af0004c0d22d95 X-Gm-Message-State: ALoCoQk6qD1bC1ifTjUWGaKcQ0Jfxoe5gSYQnDaaYzFVQJqkvKWpPGR7Arzlc01rdStI1ZcogRMx Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Question on DHCPv6 / RFC3315 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 01:20:56 -0000 --bcaec5555556e5af0004c0d22d95 Content-Type: text/plain; charset=ISO-8859-1 I would say no. By changing from DHCPv6 Enabled to Static, it should no longer be doing DHCP. On Thu, May 24, 2012 at 11:40 AM, a r pradeep wrote: > Hello All > > Had a question on RFC 3315, Section 18.1.2 Creation and Transmission of > Confirm messages > > When a client changes its configuration from dhcpv6 enabled to static, is > this considered as moving to new link and is the client required to send > out a Confirm message ? > > Thanks > pradeep > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > > -- *Andre Kostur* Senior Product Design Engineer *P:* 604-678-2864 *E:* akostur@incognito.com *Toll-Free:* 1-800-877-1856 *F:* 604-678-2864 *VoIP:* sip:864@sip.incognito.com [image: Incognito Software Inc.] --bcaec5555556e5af0004c0d22d95 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I would say no. =A0By changing from DHCPv6 Enabled to Stat= ic, it should no longer be doing DHCP.

On= Thu, May 24, 2012 at 11:40 AM, a r pradeep <pradeepar@gmail.com&g= t; wrote:
Hello All
=A0
Had a question on RFC 33= 15, Section 18.1.2 Creation and Transmission of Confirm messages
=A0
= When a client changes its configuration from dhcpv6 enabled to static, is t= his considered as moving to new link and is the client required to send out= a Confirm message ?
=A0
Thanks
pradeep
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dhcwg




--
<= tbody>
Andre Kostur<= /b>
Senior Product Design Engineer
P: 604-678-2864
E: akostur@incognito.com
Toll-Free: 1-800= -877-1856

F: 604-678-2864
VoIP: = sip:864@sip.incognito.com

3D"Incognito


--bcaec5555556e5af0004c0d22d95-- From Stephen.Jacob@nominum.com Thu May 24 23:37:52 2012 Return-Path: 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 9BE6F11E80F9 for ; Thu, 24 May 2012 23:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 GztnLjnuzera for ; Thu, 24 May 2012 23:37:50 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id 9E26811E80F1 for ; Thu, 24 May 2012 23:37:49 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKT78ou082zlyX+s5iXEdxmdkwEb+K8CAn@postini.com; Thu, 24 May 2012 23:37:49 PDT Received: by shell-too.nominum.com (Postfix, from userid 11053) id 658041B80B0; Thu, 24 May 2012 23:37:47 -0700 (PDT) Date: Thu, 24 May 2012 23:37:47 -0700 From: Stephen Jacob To: "Bernie Volz (volz)" Message-ID: <20120525063747.GD20816@shell-too.nominum.com> Mail-Followup-To: "Bernie Volz (volz)" , "Gaurav Halwasia (ghalwasi)" , dhcwg@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i X-URI: http://www.nominum.com/ Organization: Nominum, Inc. Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Comments on draft-troan-dhc-dhcpv6-stateful-issues-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 06:37:52 -0000 This is actually extremely interesting to me. I believe there remains even further confusion with the cited section. I will explain the issues I ran into recently below the quoted context! On Thu, May 24, 2012 at 02:29:52PM -0500, Bernie Volz (volz) wrote: > Comments below (BV>). ... > 1.)Section 3.1 > > Replace Section 17.1.3 > ction-17.1.3> : (existing errata) > > The client MUST ignore any Advertise message that includes a Status > Code option containing the value NoAddrsAvail, with the exception > that the client MAY display the associated status message to the > user. > > With: > > The client MUST ignore any IAs in an Advertise message that > includes a Status Code option containing the value NoAddrsAvail, > with the exception that the client MAY display the associated > status message to the user. An Advertise message without any IA > options MUST be ignored. > > Is this only applicable to IA_NA.? I guess in case client sends SOLICIT > with both IA_NA and IA_PD. Then in that case I guess we should mention > "NoPrefixAvail" as well. > > BV> It is applicable to IA_NA and IA_TA as those are the cases that end > up with the Status Code option of NoAddsAvailable in the "main" part of > the message - not in each IA_NA/IA_TA. (IA_PD puts the NoPrefixAvail > Status Code option in the IA_PD itself. This is what we wish had been > specified for IA_NA/IA_TA but was not.) Now, here's where it gets even more convoluted: (I don't know if deconfusing this convolutedness is in scope for this draft, but I'd very much like any opinions/solutions from other implementors even if it is not). ----- As mentioned above, in RFC 3315, section 17.1.3, it says: "The client MUST ignore any Advertise message that includes a Status Code option containing the value NoAddrsAvail, with the exception that the client MAY display the associated status message to the user." and in section 17.2.2 it says: "If the server will not assign any addresses to any IAs in a subsequent Request from the client, the server MUST send an Advertise message to the client that includes only a Status Code option with code NoAddrsAvail and a status message for the user, a Server Identifier option with the server's DUID, and a Client Identifier option with the client's DUID." In RFC 3633, section 11.2, it says: "If the delegating router will not assign any prefixes to any IA_PDs in a subsequent Request from the requesting router, the delegating router MUST send an Advertise message to the requesting router that includes the IA_PD with no prefixes in the IA_PD and a Status Code option in the IA_PD containing status code NoPrefixAvail ..." This is different from IA_NA/IA_TA handling in that if you are not going to grant leases on addresses (as opposed to prefixes), you can omit the IA_NA/IA_TA options and just include Status Code NoAddrsAvail at the top level. RFC 3633 does not appear to say anything about status code in the top level options (outside IA_PD options -- neither specifying any new behaviour nor overriding/contradicting RFC 3315) other than in section 12.1 where it says: "Handling of Status Codes options in received Reply messages is described in section 18.1.8, "Receipt of Reply Messages" of RFC 3315. The NoPrefixAvail Status Code is handled in the same manner as the NoAddrsAvail Status Code." ... which by reference to RFC 3315 implies behaviour matching RFC 3315. RFC 3315 section 18.1.8 does not explicitly address the use of the Status Code option at the top level. One might assume that, then, behaviour specified elsewhere in RFC 3315 would apply, but would that be a correct assumption? Reading between the lines, I might expect that since a DHCP server MUST send IA_PD containing Status Code NoPrefixAvail when it is not going to grant a lease on a prefix that: (a) that should supplant sending a Status Code at the top level, so one should omit Status Code in the top level options; or (b) another possibility is that one should also include Status Code at the top level, but with value NoPrefixAvail; or (c) one should, in fact, literally follow RFC 3315 and since no *addresses* will be offered, include Status Code at the top level with value NoAddrsAvail in spite of also including the IA_PD option with Status Code NoPrefixAvail. The problem with option C is that ... let's say a Solicit contains only an IA_PD (no IA_NA/IA_TA) and the DHCP server responds with a valid prefix for the IA_PD option ... by a strict reading of RFC 3315 along side RFC 3633, since no *addresses* are being offered, there should be a Status Code of NoAddrsAvail at the top level. I'm nearly certain that that is not intended behaviour, since by a strict reading of the two RFCs a DHCP client should then ignore the valid IA_PD option. What to do when the DHCP server receives IA_NA and IA_PD, does not grant a lease on an address to the former and does grant a lease on a prefix to the latter is even muddier. Logic suggests to me in that case no top-level Status Code. Only one in the IA_NA option. Strict reading of the RFCs does not *appear* to support this belief, however. Since a compliant DHCP client must ignore messages containing Status Code NoAddrAvail at the top level (RFC 3315), and due to the MUST on inclusion of the IA_PD option (with Status Code NoPrefixAvail) (RFC 3633), I _suspect_ that the _intention_ is that implementations should instead omit Status Code at the top level in this case, or should use the value NoPrefixAvail (which seems redundant, with the mandatory inclusion of IA_PD with its own Status Code option). Our DHCP implementation does option C at present. I need to figure out whether that is correct and, if not, change the implementation. I expect this may be of interest to other implementors, too. Regards, Stephen -- Stephen Jacob | Stephen.Jacob@nominum.com | +1 650 381 6051 Nominum, Inc. | http://www.nominum.com/ | +1 650 381 6000 From ghalwasi@cisco.com Fri May 25 01:12:07 2012 Return-Path: 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 6EE6121F855F for ; Fri, 25 May 2012 01:12:07 -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 gewcMjI7TuCb for ; Fri, 25 May 2012 01:12:04 -0700 (PDT) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA4D21F8585 for ; Fri, 25 May 2012 01:12:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ghalwasi@cisco.com; l=25287; q=dns/txt; s=iport; t=1337933521; x=1339143121; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=gs8ivJP7gFpH5gscmRNBFWAc2yat9KF3VXPJA9xK8ts=; b=ecUhGs6UyRsnUU+gkDyPNn16eC9KlMQJUWgI01qJ6UfHsY3YGt7k0uoy JdWSUINHrabwPdqQahqKXC+o0JAWGig2Pl4WC17ZEtNcKF1oAJHzIaUko miItjUdM0/13qtTX/fGWXvCazVC9pMeA69VRpOpLII5ukUQrG6nllyhVl 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar0EAFQ9v09Io8UY/2dsb2JhbABEgkWofgGKU4IVAQEBBBIBCREDWQIBCBEEAQELBhAHAQYBRQkIAQEEAQoICBMHh2sLmz6gAosBhGZgA4g9jWqMfYFkgmiBTgc X-IronPort-AV: E=Sophos;i="4.75,655,1330905600"; d="scan'208,217";a="12996859" Received: from vla196-nat.cisco.com (HELO bgl-core-2.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 25 May 2012 08:11:57 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q4P8Bvpf025801 for ; Fri, 25 May 2012 08:11:57 GMT Received: from xmb-bgl-41e.cisco.com ([72.163.129.220]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 25 May 2012 13:41:57 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD3A4E.0D82F8AE" Date: Fri, 25 May 2012 13:40:08 +0530 Message-ID: <3CF88B99A9ED504197498BC6F6F04B81069F0308@XMB-BGL-41E.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] Comments on draft-troan-dhc-dhcpv6-stateful-issues-00 Thread-Index: Ac05uKdEL2fp8FLMS7ymS5aexC6oDgAKig9QAA/9SaA= References: From: "Gaurav Halwasia (ghalwasi)" To: "Bernie Volz (volz)" , X-OriginalArrivalTime: 25 May 2012 08:11:57.0690 (UTC) FILETIME=[0DCB4DA0:01CD3A4E] Subject: Re: [dhcwg] Comments on draft-troan-dhc-dhcpv6-stateful-issues-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 08:12:07 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD3A4E.0D82F8AE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Bernie for clarification. =20 I believe, it is possible that a particular server is willing to offer only a subset of IA_'s which has been requested. In that case, what's the use of including the other IA_ in the subsequent renew/rebind. As in this case server will anyway only renew only one IA_. ? Are we suggesting that a client at any given point of time should only be talking to one server after the advertise is accepted. =20 BV> What harm is there in continuing to include this in the subsequent operations? If the server's policy prohibits returning addresses or delegated prefixes for these other IA types, there is no harm. The main assumption is that clients are in a single administrative domain and thus talking to another server will be unlikely to help (except of course in the case of misconfiguration, but better that the issue is detected early and dealt with). =20 [Gaurav] I don't see any harm in including not assigned IA_'s in subsequent renew and rebind. I wanted to clarify that with this text, we implicitly mean that client can only be associated with one server at a time. So we are saying that we can not have a deployment where 2 dhcpv6 servers (one doing IA_NA and other doing IA_PD) can be present. Also what if client first did IA_NA and at any later point of time it wants to do IA_PD.=20 1. Does it need to wait for the next renew time to get expired before it can ask IA_PD along.?=20 2. So are we saying that it should not send SOLICIT for IA_PD anytime in between.? If we are still allowing SOLICIT, should it only accept ADVERTISE from the server (which initially gave IA_NA)=20 =20 Thanks, Gaurav From: Bernie Volz (volz)=20 Sent: Friday, May 25, 2012 1:00 AM To: Gaurav Halwasia (ghalwasi); dhcwg@ietf.org Subject: RE: [dhcwg] Comments on draft-troan-dhc-dhcpv6-stateful-issues-00 =20 Hi and thanks for reading and commenting! =20 Comments below (BV>). =20 - Bernie =20 From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Gaurav Halwasia (ghalwasi) Sent: Thursday, May 24, 2012 11:03 AM To: dhcwg@ietf.org Subject: [dhcwg] Comments on draft-troan-dhc-dhcpv6-stateful-issues-00 =20 I have read this informational draft and I have couple of comments so far. =20 1.)Section 3.1 Replace Section 17.1.3 : (existing errata) =20 =20 The client MUST ignore any Advertise message that includes a Status Code option containing the value NoAddrsAvail, with the exception that the client MAY display the associated status message to the user. =20 With: =20 =20 The client MUST ignore any IAs in an Advertise message that includes a Status Code option containing the value NoAddrsAvail, with the exception that the client MAY display the associated status message to the user. An Advertise message without any IA options MUST be ignored. =20 Is this only applicable to IA_NA.? I guess in case client sends SOLICIT with both IA_NA and IA_PD. Then in that case I guess we should mention "NoPrefixAvail" as well. =20 BV> It is applicable to IA_NA and IA_TA as those are the cases that end up with the Status Code option of NoAddsAvailable in the "main" part of the message - not in each IA_NA/IA_TA. (IA_PD puts the NoPrefixAvail Status Code option in the IA_PD itself. This is what we wish had been specified for IA_NA/IA_TA but was not.) =20 2.) Section 3.6 Proposed solution: the client should keep a single session with the server. The client should continue with the IA_ options received, while continuing to request the other IA options in subsequent messages to the server. That means continue to include the empty unanswered IAs in subsequent Renew and Rebind messages. =20 I believe, it is possible that a particular server is willing to offer only a subset of IA_'s which has been requested. In that case, what's the use of including the other IA_ in the subsequent renew/rebind. As in this case server will anyway only renew only one IA_. ? Are we suggesting that a client at any given point of time should only be talking to one server after the advertise is accepted. =20 BV> What harm is there in continuing to include this in the subsequent operations? If the server's policy prohibits returning addresses or delegated prefixes for these other IA types, there is no harm. The main assumption is that clients are in a single administrative domain and thus talking to another server will be unlikely to help (except of course in the case of misconfiguration, but better that the issue is detected early and dealt with). =20 - Bernie ------_=_NextPart_001_01CD3A4E.0D82F8AE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
Thanks Bernie for =
clarification.
 
<snip&=
gt;
I believe, it is possible that a particular =
server is willing to offer only a subset of IA_’s which has been =
requested. In that case, what’s the use of including the other IA_ =
in the subsequent renew/rebind. As in this case server will anyway only =
renew only one IA_. ? Are we suggesting that a client at any given point =
of time should only be talking to one server after the advertise is =
accepted.
 
BV> What harm is there in continuing to include this in the =
subsequent operations? If the server’s policy prohibits returning =
addresses or delegated prefixes for these other IA types, there is no =
harm. The main assumption is that clients are in a single administrative =
domain and thus talking to another server will be unlikely to help =
(except of course in the case of misconfiguration, but better that the =
issue is detected early and dealt with).

</snip>

 

[Gaurav] I don’t = see any harm in including not assigned IA_’s in subsequent renew = and rebind.  I wanted to clarify that with this text, we implicitly = mean that client can only be associated with one server at a time.  = So we are saying that we can not have a deployment where 2 dhcpv6 = servers (one doing IA_NA and other doing IA_PD) can be present.  = Also what if client first did IA_NA and at any later point of time it = wants to do IA_PD.

1.       = Does it = need to wait for the next renew time to get expired before it can ask = IA_PD along.?

2.       = So are we = saying that it should not send SOLICIT for IA_PD anytime in between.? If = we are still allowing SOLICIT, should it only accept ADVERTISE from the = server (which initially gave IA_NA)

 

Thanks,

Gaurav

From:= = Bernie Volz (volz)
Sent: Friday, May 25, 2012 1:00 = AM
To: Gaurav Halwasia (ghalwasi); = dhcwg@ietf.org
Subject: RE: [dhcwg] Comments on = draft-troan-dhc-dhcpv6-stateful-issues-00

 

Hi and thanks for reading and = commenting!

 

Comments below = (BV>).

 

-          = Bernie

 

From:= = dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of = Gaurav Halwasia (ghalwasi)
Sent: Thursday, May 24, 2012 = 11:03 AM
To: dhcwg@ietf.org
Subject: [dhcwg] = Comments on = draft-troan-dhc-dhcpv6-stateful-issues-00

 

I have read this = informational draft and I have couple of comments so = far.

 

1.)Section = 3.1

   =
Replace Section 17.1.3: (existing =
errata)
 
 
      The client =
MUST ignore any Advertise message that includes a =
Status
      Code option =
containing the value NoAddrsAvail, with the =
exception
      that the =
client MAY display the associated status message to =
the
      =
user.
 
   With:
 
 
      The client =
MUST ignore any IAs in an Advertise message that
      includes a =
Status Code option containing the value =
NoAddrsAvail,
      with the =
exception that the client MAY display the =
associated
      status message =
to the user. An Advertise message without any IA
      options MUST =
be ignored.

 

Is this only applicable to =
IA_NA.? I guess in case client sends SOLICIT with both IA_NA and IA_PD. =
Then in that case I guess we should mention “NoPrefixAvail” =
as well.
 
BV> It is applicable to IA_NA and IA_TA as those are the cases =
that end up with the Status Code option of NoAddsAvailable in the =
“main” part of the message – not in each IA_NA/IA_TA. =
(IA_PD puts the NoPrefixAvail Status Code option in the IA_PD itself. =
This is what we wish had been specified for IA_NA/IA_TA but was =
not.)
 
2.) Section =
3.6
   =
Proposed solution: the client should keep a single session with =
the
   =
server.  The client should continue with the IA_ options =
received,
   =
while continuing to request the other IA options in =
subsequent
   =
messages to the server.  That means continue to include the =
empty
   =
unanswered IAs in subsequent Renew and Rebind =
messages.
 
I believe, it =
is possible that a particular server is willing to offer only a subset =
of IA_’s which has been requested. In that case, what’s the =
use of including the other IA_ in the subsequent renew/rebind. As in =
this case server will anyway only renew only one IA_. ? Are we =
suggesting that a client at any given point of time should only be =
talking to one server after the advertise is =
accepted.
 
BV> What harm is there in continuing to include this in the =
subsequent operations? If the server’s policy prohibits returning =
addresses or delegated prefixes for these other IA types, there is no =
harm. The main assumption is that clients are in a single administrative =
domain and thus talking to another server will be unlikely to help =
(except of course in the case of misconfiguration, but better that the =
issue is detected early and dealt =
with).
 
-          =
Bernie
------_=_NextPart_001_01CD3A4E.0D82F8AE-- From volz@cisco.com Fri May 25 03:29:12 2012 Return-Path: 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 CC3FE21F85FF for ; Fri, 25 May 2012 03:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.448 X-Spam-Level: X-Spam-Status: No, score=-10.448 tagged_above=-999 required=5 tests=[AWL=0.150, 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 ZOSFxWvIuTa6 for ; Fri, 25 May 2012 03:29:08 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 4ADF221F85FD for ; Fri, 25 May 2012 03:29:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=34102; q=dns/txt; s=iport; t=1337941746; x=1339151346; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=51mu/SiRUmNpsFnV/27shZU17o4eH8zYvbQR2g4v9jo=; b=bTh1ptDMdvg+tjwOAc171pWn27sWVE85LONgQshocpq7TdtBd7E1vNih S+1glu2vak5RFQuDdB34eGn3gWnBDe/PWOwi79pnYZ72Q+RNhkSRW83tq L6Sl9M6hzFcpSFHEcKKaxgVHm0XseQHHXJtG1sauNmNXzg06Dk3T2Qc/S 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFACBev0+tJV2a/2dsb2JhbABEgkWpEAGJTYEHghUBAQEDARIBCREDTgsCAQgRBAEBCwYQAQYBBgFFCQgBAQQBEggTB4dmBQubQJ91iwGEZmADiD+NaIx9gWSCfoE4Bw X-IronPort-AV: E=Sophos;i="4.75,655,1330905600"; d="scan'208,217";a="86587612" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-2.cisco.com with ESMTP; 25 May 2012 10:29:05 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q4PAT5gL009467 for ; Fri, 25 May 2012 10:29:05 GMT Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 25 May 2012 05:29:05 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD3A61.3594D7F8" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 25 May 2012 05:29:03 -0500 Message-ID: In-Reply-To: <3CF88B99A9ED504197498BC6F6F04B81069F0308@XMB-BGL-41E.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] Comments on draft-troan-dhc-dhcpv6-stateful-issues-00 Thread-Index: Ac05uKdEL2fp8FLMS7ymS5aexC6oDgAKig9QAA/9SaAADz3acA== References: <3CF88B99A9ED504197498BC6F6F04B81069F0308@XMB-BGL-41E.cisco.com> From: "Bernie Volz (volz)" To: "Gaurav Halwasia (ghalwasi)" , X-OriginalArrivalTime: 25 May 2012 10:29:05.0025 (UTC) FILETIME=[35AAFF10:01CD3A61] Subject: Re: [dhcwg] Comments on draft-troan-dhc-dhcpv6-stateful-issues-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 10:29:12 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD3A61.3594D7F8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable BTW - we really should be referencing draft-ietf-dhc-dhcpv6-stateful-issues-00. I hope that is the draft that you looked at. =20 > I wanted to clarify that with this text, we implicitly mean that client can only be associated with one server at a time.=20 =20 We are pretty much saying that, per interface, a client is associated with one server. There isn't anything to prohibit multiple servers, but without some additional work (which I mentioned at the DHC WG meeting in Paris) to support multiple administrative domains, it is not possible for a client to know whether it is in ONE or MULTIPLE administrative domains. And, in probably 99.9% of the cases, it is in a SINGLE administrative domain. So, let's make sure that things work well in that environment before worrying about the 0.1% (perhaps I should have said 99% and 1% based on the recent "Occupy" movements). =20 1. Does it need to wait for the next renew time to get expired before it can ask IA_PD along.?=20 =20 Yes. Best practice is that it should renew early and renew what it has and also ask for the IA_PD. But, the client may also "restart" by doing a Solicit (for IA_NA and IA_PD) - I think the renew is best though. The only negative with starting with the Renew is that you don't really want to wait until T2 to find another server if the original server is down. So we might want to think some more about whether the retransmission rules should be different. =20 2. So are we saying that it should not send SOLICIT for IA_PD anytime in between.? If we are still allowing SOLICIT, should it only accept ADVERTISE from the server (which initially gave IA_NA)=20 =20 No - we are not disallowing this. We are saying that Renew is OK to get new bindings. If client sends Solicit, it can accept whatever Advertisement it likes (per the "rules" in RFC 3315/3633).=20 =20 We might need an additional section in the draft to specify this behavior. =20 - Bernie =20 From: Gaurav Halwasia (ghalwasi)=20 Sent: Friday, May 25, 2012 4:10 AM To: Bernie Volz (volz); 'dhcwg@ietf.org' Subject: RE: [dhcwg] Comments on draft-troan-dhc-dhcpv6-stateful-issues-00 =20 Thanks Bernie for clarification. =20 I believe, it is possible that a particular server is willing to offer only a subset of IA_'s which has been requested. In that case, what's the use of including the other IA_ in the subsequent renew/rebind. As in this case server will anyway only renew only one IA_. ? Are we suggesting that a client at any given point of time should only be talking to one server after the advertise is accepted. =20 BV> What harm is there in continuing to include this in the subsequent operations? If the server's policy prohibits returning addresses or delegated prefixes for these other IA types, there is no harm. The main assumption is that clients are in a single administrative domain and thus talking to another server will be unlikely to help (except of course in the case of misconfiguration, but better that the issue is detected early and dealt with). =20 [Gaurav] I don't see any harm in including not assigned IA_'s in subsequent renew and rebind. I wanted to clarify that with this text, we implicitly mean that client can only be associated with one server at a time. So we are saying that we can not have a deployment where 2 dhcpv6 servers (one doing IA_NA and other doing IA_PD) can be present. Also what if client first did IA_NA and at any later point of time it wants to do IA_PD.=20 1. Does it need to wait for the next renew time to get expired before it can ask IA_PD along.?=20 2. So are we saying that it should not send SOLICIT for IA_PD anytime in between.? If we are still allowing SOLICIT, should it only accept ADVERTISE from the server (which initially gave IA_NA)=20 =20 Thanks, Gaurav From: Bernie Volz (volz)=20 Sent: Friday, May 25, 2012 1:00 AM To: Gaurav Halwasia (ghalwasi); dhcwg@ietf.org Subject: RE: [dhcwg] Comments on draft-troan-dhc-dhcpv6-stateful-issues-00 =20 Hi and thanks for reading and commenting! =20 Comments below (BV>). =20 - Bernie =20 From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Gaurav Halwasia (ghalwasi) Sent: Thursday, May 24, 2012 11:03 AM To: dhcwg@ietf.org Subject: [dhcwg] Comments on draft-troan-dhc-dhcpv6-stateful-issues-00 =20 I have read this informational draft and I have couple of comments so far. =20 1.)Section 3.1 Replace Section 17.1.3 : (existing errata) =20 =20 The client MUST ignore any Advertise message that includes a Status Code option containing the value NoAddrsAvail, with the exception that the client MAY display the associated status message to the user. =20 With: =20 =20 The client MUST ignore any IAs in an Advertise message that includes a Status Code option containing the value NoAddrsAvail, with the exception that the client MAY display the associated status message to the user. An Advertise message without any IA options MUST be ignored. =20 Is this only applicable to IA_NA.? I guess in case client sends SOLICIT with both IA_NA and IA_PD. Then in that case I guess we should mention "NoPrefixAvail" as well. =20 BV> It is applicable to IA_NA and IA_TA as those are the cases that end up with the Status Code option of NoAddsAvailable in the "main" part of the message - not in each IA_NA/IA_TA. (IA_PD puts the NoPrefixAvail Status Code option in the IA_PD itself. This is what we wish had been specified for IA_NA/IA_TA but was not.) =20 2.) Section 3.6 Proposed solution: the client should keep a single session with the server. The client should continue with the IA_ options received, while continuing to request the other IA options in subsequent messages to the server. That means continue to include the empty unanswered IAs in subsequent Renew and Rebind messages. =20 I believe, it is possible that a particular server is willing to offer only a subset of IA_'s which has been requested. In that case, what's the use of including the other IA_ in the subsequent renew/rebind. As in this case server will anyway only renew only one IA_. ? Are we suggesting that a client at any given point of time should only be talking to one server after the advertise is accepted. =20 BV> What harm is there in continuing to include this in the subsequent operations? If the server's policy prohibits returning addresses or delegated prefixes for these other IA types, there is no harm. The main assumption is that clients are in a single administrative domain and thus talking to another server will be unlikely to help (except of course in the case of misconfiguration, but better that the issue is detected early and dealt with). =20 - Bernie ------_=_NextPart_001_01CD3A61.3594D7F8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

BTW – we really should be referencing = draft-ietf-dhc-dhcpv6-stateful-issues-00. I hope that is the draft that = you looked at.

 

> I wanted to clarify that with this text, we = implicitly mean that client can only be associated with one server at a = time. 

 

We are pretty much = saying that, per interface, a client is associated with one server. = There isn’t anything to prohibit multiple servers, but without = some additional work (which I mentioned at the DHC WG meeting in Paris) = to support multiple administrative domains, it is not possible for a = client to know whether it is in ONE or MULTIPLE administrative domains. = And, in probably 99.9% of the cases, it is in a SINGLE administrative = domain. So, let’s make sure that things work well in that = environment before worrying about the 0.1% (perhaps I should have said = 99% and 1% based on the recent “Occupy” = movements).

 

1.       = Does it = need to wait for the next renew time to get expired before it can ask = IA_PD along.?

 

Yes. Best practice is = that it should renew early and renew what it has and also ask for the = IA_PD. But, the client may also “restart” by doing a Solicit = (for IA_NA and IA_PD) – I think the renew is best though. The only = negative with starting with the Renew is that you don’t really = want to wait until T2 to find another server if the original server is = down. So we might want to think some more about whether the = retransmission rules should be different.

 

2.       = So are we = saying that it should not send SOLICIT for IA_PD anytime in between.? If = we are still allowing SOLICIT, should it only accept ADVERTISE from the = server (which initially gave IA_NA)

 

No – we are not = disallowing this. We are saying that Renew is OK to get new bindings. If = client sends Solicit, it can accept whatever Advertisement it likes (per = the “rules” in RFC 3315/3633).

 

We might need an = additional section in the draft to specify this = behavior.

 

-          = Bernie

 

From:= = Gaurav Halwasia (ghalwasi)
Sent: Friday, May 25, 2012 4:10 = AM
To: Bernie Volz (volz); 'dhcwg@ietf.org'
Subject: = RE: [dhcwg] Comments on = draft-troan-dhc-dhcpv6-stateful-issues-00

 

Thanks Bernie for =
clarification.
 
<snip&=
gt;
I believe, it is possible that a particular =
server is willing to offer only a subset of IA_’s which has been =
requested. In that case, what’s the use of including the other IA_ =
in the subsequent renew/rebind. As in this case server will anyway only =
renew only one IA_. ? Are we suggesting that a client at any given point =
of time should only be talking to one server after the advertise is =
accepted.
 
BV> What harm is there in continuing to include this in the =
subsequent operations? If the server’s policy prohibits returning =
addresses or delegated prefixes for these other IA types, there is no =
harm. The main assumption is that clients are in a single administrative =
domain and thus talking to another server will be unlikely to help =
(except of course in the case of misconfiguration, but better that the =
issue is detected early and dealt with).

</snip>

 

[Gaurav] I don’t = see any harm in including not assigned IA_’s in subsequent renew = and rebind.  I wanted to clarify that with this text, we implicitly = mean that client can only be associated with one server at a time.  = So we are saying that we can not have a deployment where 2 dhcpv6 = servers (one doing IA_NA and other doing IA_PD) can be present.  = Also what if client first did IA_NA and at any later point of time it = wants to do IA_PD.

1.       = Does it = need to wait for the next renew time to get expired before it can ask = IA_PD along.?

2.       = So are we = saying that it should not send SOLICIT for IA_PD anytime in between.? If = we are still allowing SOLICIT, should it only accept ADVERTISE from the = server (which initially gave IA_NA)

 

Thanks,

Gaurav

From:= = Bernie Volz (volz)
Sent: Friday, May 25, 2012 1:00 = AM
To: Gaurav Halwasia (ghalwasi); dhcwg@ietf.org
Subject: RE: = [dhcwg] Comments on = draft-troan-dhc-dhcpv6-stateful-issues-00

 

Hi and thanks for reading and = commenting!

 

Comments below = (BV>).

 

-          = Bernie

 

From:= = dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@iet= f.org] On Behalf Of Gaurav Halwasia = (ghalwasi)
Sent: Thursday, May 24, 2012 11:03 AM
To: = dhcwg@ietf.org
Subject: = [dhcwg] Comments on = draft-troan-dhc-dhcpv6-stateful-issues-00

 

I have read this = informational draft and I have couple of comments so = far.

 

1.)Section = 3.1

   =
Replace Section 17.1.3: (existing =
errata)
 
 
      The client =
MUST ignore any Advertise message that includes a =
Status
      Code option =
containing the value NoAddrsAvail, with the =
exception
      that the =
client MAY display the associated status message to =
the
      =
user.
 
   With:
 
 
      The client =
MUST ignore any IAs in an Advertise message that
      includes a =
Status Code option containing the value =
NoAddrsAvail,
      with the =
exception that the client MAY display the =
associated
      status message =
to the user. An Advertise message without any IA
      options MUST =
be ignored.

 

Is this only applicable to =
IA_NA.? I guess in case client sends SOLICIT with both IA_NA and IA_PD. =
Then in that case I guess we should mention “NoPrefixAvail” =
as well.
 
BV> It is applicable to IA_NA and IA_TA as those are the cases =
that end up with the Status Code option of NoAddsAvailable in the =
“main” part of the message – not in each IA_NA/IA_TA. =
(IA_PD puts the NoPrefixAvail Status Code option in the IA_PD itself. =
This is what we wish had been specified for IA_NA/IA_TA but was =
not.)
 
2.) Section =
3.6
   =
Proposed solution: the client should keep a single session with =
the
   =
server.  The client should continue with the IA_ options =
received,
   =
while continuing to request the other IA options in =
subsequent
   =
messages to the server.  That means continue to include the =
empty
   =
unanswered IAs in subsequent Renew and Rebind =
messages.
 
I believe, it =
is possible that a particular server is willing to offer only a subset =
of IA_’s which has been requested. In that case, what’s the =
use of including the other IA_ in the subsequent renew/rebind. As in =
this case server will anyway only renew only one IA_. ? Are we =
suggesting that a client at any given point of time should only be =
talking to one server after the advertise is =
accepted.
 
BV> What harm is there in continuing to include this in the =
subsequent operations? If the server’s policy prohibits returning =
addresses or delegated prefixes for these other IA types, there is no =
harm. The main assumption is that clients are in a single administrative =
domain and thus talking to another server will be unlikely to help =
(except of course in the case of misconfiguration, but better that the =
issue is detected early and dealt =
with).
 
-          =
Bernie
------_=_NextPart_001_01CD3A61.3594D7F8-- From volz@cisco.com Fri May 25 03:45:23 2012 Return-Path: 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 C51A521F85D6 for ; Fri, 25 May 2012 03:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, 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 N+HMJxxB4EtD for ; Fri, 25 May 2012 03:45:22 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id A037921F84E7 for ; Fri, 25 May 2012 03:45:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=9006; q=dns/txt; s=iport; t=1337942722; x=1339152322; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=dW8p0m5FWcEiNgQ8MVrpc5nwTt6guf9k89VytjybZwA=; b=WaHA0wO0R396T36HqrMid4dTCx8YWqZZw7sbN/+K8WMwmGZx7laedpKS 4ZAblcmhaTlI61Jk9uuv6yS5PYcoeinIZeMt6gOulP48UpIT+nBtnjPNG AdrhXIP0ECJdJd26uTXJN33lKdV4ZZEuMdZKNBDP3qR6ZuJXyaCPrbDs7 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALFhv0+tJXG8/2dsb2JhbABBA7UjgQeCFQEBAQMBEgEdCj8FBwQCAQgHCgQBAQEKBhcBBgFFCQgBAQQTCBMHh2YFC5tAn3WLAYIrgjtgA4g/jWiMfYFkgn4 X-IronPort-AV: E=Sophos;i="4.75,655,1330905600"; d="scan'208";a="86634071" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 25 May 2012 10:45:22 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q4PAjMHF017646; Fri, 25 May 2012 10:45:22 GMT Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 25 May 2012 05:45:22 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 25 May 2012 05:45:20 -0500 Message-ID: In-Reply-To: <20120525063747.GD20816@shell-too.nominum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] Comments on draft-troan-dhc-dhcpv6-stateful-issues-00 Thread-Index: Ac06QOfpB+YCOuC4SFifU+LuLN2whwAIIOBA References: <20120525063747.GD20816@shell-too.nominum.com> From: "Bernie Volz (volz)" To: "Stephen Jacob" X-OriginalArrivalTime: 25 May 2012 10:45:22.0038 (UTC) FILETIME=[7C035960:01CD3A63] Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Comments on draft-troan-dhc-dhcpv6-stateful-issues-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 10:45:23 -0000 If a client requests both IA_NA and IA_PD, here is what our server (Cisco Prime Network Registrar does): - If neither are possible: - Top level option has Status Code with NoAddrsAvail - IA_PA has Status Code with NoPrefixAvail - If only IA_NA possible: - IA_NA has binding information - IA_PD has Status Code with NoPrefixAvail - If only IA_PD possible: - Top level option has Status Code with NoAddrsAvail - IA_PD has binding information My read of RFC 3315 says that the above is correct with respect to IA_NA/IA_TA. (Note that you can replace IA_NA with IA_TA in the above, or add IA_TA.) BTW, you would NEVER include NoAddrsAvail if no IA_NA/IA_TA options. My read of RFC 3633 says that the above is correct with respect to IA_PD. A client should only treat a message with Status Code with NoAddrsAvail to have "failed" with respect to IA_NA/IA_TA. Not, IA_PD. This is exactly what we are suggesting the behavior to be in the draft. While I agree that this Status Code difference is rather odd and I had pushed for moving the Status Code with NoAddrsAvail into the IA_NA/TA options at the time of RFC 3315, but it didn't happen. (Think of the case where IA_NA and IA_TA are included but server only gives out IA_NA ... in this case, in Advertise IA_NA has bindings and IA_TA is empty. That seemed a bit weird to me - if empty (no bindings) was OK, why did we need a Status Code? And why only report the status if ALL IA_NA/IA_TA fail? I think RFC 3633 got it right as to where the status should be.) And, I think it too late to change this because it would likely break many existing client implementations (such as those that only do IA_NA/TA). We considered this when writing the ID, but felt it too dangerous to existing implements to propose such a change (to move NoAddrsAvail into IA_NA/IA_TA instead of at top level). BTW: I can't say how well the above server implementation plays with all clients because frankly it is likely not that usual for a client to request IA_NA/TA and IA_PD and have a server that only supports one. I can say we haven't heard of any complaints and the server is in use for DHCPv6 in a lot of places. You statement: >Since a compliant DHCP client must ignore messages containing Status Code NoAddrAvail at the top level (RFC 3315), This is, IMHO, only with respect to the IA options specified in RFC 3315. - Bernie -----Original Message----- From: Stephen Jacob [mailto:Stephen.Jacob@nominum.com]=20 Sent: Friday, May 25, 2012 2:38 AM To: Bernie Volz (volz) Cc: Gaurav Halwasia (ghalwasi); dhcwg@ietf.org Subject: Re: [dhcwg] Comments on draft-troan-dhc-dhcpv6-stateful-issues-00 This is actually extremely interesting to me. I believe there remains even further confusion with the cited section. I will explain the issues I ran into recently below the quoted context! On Thu, May 24, 2012 at 02:29:52PM -0500, Bernie Volz (volz) wrote: > Comments below (BV>). ... > 1.)Section 3.1 >=20 > Replace Section 17.1.3 > se > ction-17.1.3> : (existing errata) > > The client MUST ignore any Advertise message that includes a Status > Code option containing the value NoAddrsAvail, with the exception > that the client MAY display the associated status message to the > user. > > With: > > The client MUST ignore any IAs in an Advertise message that > includes a Status Code option containing the value NoAddrsAvail, > with the exception that the client MAY display the associated > status message to the user. An Advertise message without any IA > options MUST be ignored. > > Is this only applicable to IA_NA.? I guess in case client sends=20 > SOLICIT with both IA_NA and IA_PD. Then in that case I guess we should > mention "NoPrefixAvail" as well. > > BV> It is applicable to IA_NA and IA_TA as those are the cases that=20 > BV> end > up with the Status Code option of NoAddsAvailable in the "main" part=20 > of the message - not in each IA_NA/IA_TA. (IA_PD puts the=20 > NoPrefixAvail Status Code option in the IA_PD itself. This is what we=20 > wish had been specified for IA_NA/IA_TA but was not.) Now, here's where it gets even more convoluted: (I don't know if deconfusing this convolutedness is in scope for this draft, but I'd very much like any opinions/solutions from other implementors even if it is not). ----- As mentioned above, in RFC 3315, section 17.1.3, it says: "The client MUST ignore any Advertise message that includes a Status Code option containing the value NoAddrsAvail, with the exception that the client MAY display the associated status message to the user." and in section 17.2.2 it says: "If the server will not assign any addresses to any IAs in a subsequent Request from the client, the server MUST send an Advertise message to the client that includes only a Status Code option with code NoAddrsAvail and a status message for the user, a Server Identifier option with the server's DUID, and a Client Identifier option with the client's DUID." In RFC 3633, section 11.2, it says: "If the delegating router will not assign any prefixes to any IA_PDs in a subsequent Request from the requesting router, the delegating router MUST send an Advertise message to the requesting router that includes the IA_PD with no prefixes in the IA_PD and a Status Code option in the IA_PD containing status code NoPrefixAvail ..." This is different from IA_NA/IA_TA handling in that if you are not going to grant leases on addresses (as opposed to prefixes), you can omit the IA_NA/IA_TA options and just include Status Code NoAddrsAvail at the top level. RFC 3633 does not appear to say anything about status code in the top level options (outside IA_PD options -- neither specifying any new behaviour nor overriding/contradicting RFC 3315) other than in section 12.1 where it says: "Handling of Status Codes options in received Reply messages is described in section 18.1.8, "Receipt of Reply Messages" of RFC 3315. The NoPrefixAvail Status Code is handled in the same manner as the NoAddrsAvail Status Code." ... which by reference to RFC 3315 implies behaviour matching RFC 3315. RFC 3315 section 18.1.8 does not explicitly address the use of the Status Code option at the top level. One might assume that, then, behaviour specified elsewhere in RFC 3315 would apply, but would that be a correct assumption? Reading between the lines, I might expect that since a DHCP server MUST send IA_PD containing Status Code NoPrefixAvail when it is not going to grant a lease on a prefix that: (a) that should supplant sending a Status Code at the top level, so one should omit Status Code in the top level options; or (b) another possibility is that one should also include Status Code at the top level, but with value NoPrefixAvail; or (c) one should, in fact, literally follow RFC 3315 and since no *addresses* will be offered, include Status Code at the top level with value NoAddrsAvail in spite of also including the IA_PD option with Status Code NoPrefixAvail. The problem with option C is that ... let's say a Solicit contains only an IA_PD (no IA_NA/IA_TA) and the DHCP server responds with a valid prefix for the IA_PD option ... by a strict reading of RFC 3315 along side RFC 3633, since no *addresses* are being offered, there should be a Status Code of NoAddrsAvail at the top level. I'm nearly certain that that is not intended behaviour, since by a strict reading of the two RFCs a DHCP client should then ignore the valid IA_PD option. What to do when the DHCP server receives IA_NA and IA_PD, does not grant a lease on an address to the former and does grant a lease on a prefix to the latter is even muddier. Logic suggests to me in that case no top-level Status Code. Only one in the IA_NA option. Strict reading of the RFCs does not *appear* to support this belief, however. Since a compliant DHCP client must ignore messages containing Status Code NoAddrAvail at the top level (RFC 3315), and due to the MUST on inclusion of the IA_PD option (with Status Code NoPrefixAvail) (RFC 3633), I _suspect_ that the _intention_ is that implementations should instead omit Status Code at the top level in this case, or should use the value NoPrefixAvail (which seems redundant, with the mandatory inclusion of IA_PD with its own Status Code option). Our DHCP implementation does option C at present. I need to figure out whether that is correct and, if not, change the implementation. I expect this may be of interest to other implementors, too. Regards, Stephen -- Stephen Jacob | Stephen.Jacob@nominum.com | +1 650 381 6051 Nominum, Inc. | http://www.nominum.com/ | +1 650 381 6000