From Internet-Drafts@ietf.org Mon May 2 08:45:02 2011 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 EDAF1E06CB; Mon, 2 May 2011 08:45:02 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6L9LoeerrlMC; Mon, 2 May 2011 08:45:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B9F2E06DE; Mon, 2 May 2011 08:45:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.52 Message-ID: <20110502154502.27342.47554.idtracker@ietfa.amsl.com> Date: Mon, 02 May 2011 08:45:02 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dhcpv4-bulk-leasequery-04.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, 02 May 2011 15:45:03 -0000 --NextPart 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. Title : Bulk DHCPv4 Lease Query Author(s) : K. Kinnear, et al Filename : draft-ietf-dhc-dhcpv4-bulk-leasequery-04.txt Pages : 38 Date : 2011-05-02 The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Leasequery extension allows a requestor to request information about DHCPv4 bindings. This mechanism is limited to queries for individual bindings. In some situations individual binding queries may not be efficient, or even possible. This document extends the DHCPv4 Leasequery protocol to allow for bulk transfer of DHCPv4 address binding data via TCP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv4-bulk-leasequery-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dhc-dhcpv4-bulk-leasequery-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-05-02083655.I-D@ietf.org> --NextPart-- From volz@cisco.com Mon May 2 09:16:35 2011 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 B21E5E06CB for ; Mon, 2 May 2011 09:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.3 X-Spam-Level: X-Spam-Status: No, score=-9.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qgLy7EvHx+dS for ; Mon, 2 May 2011 09:16:34 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by ietfa.amsl.com (Postfix) with ESMTP id 95572E0688 for ; Mon, 2 May 2011 09:16:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=2860; q=dns/txt; s=iport; t=1304352994; x=1305562594; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=HAySkJNdrU5kfgBIpUF4gaLtUq48RfDZtTg5QGbiAJA=; b=ksM0Wsx8oCOtpHM+o0RsS3wYPfFRrVNqnXM+jPD+C9H5HUPwHDa11clq gSsnENd7j+KoFfEqWUFnUppk1/WL2Ut5gqr4eDu3W+wv2grFQWsj3Edug kcMS8E1WnFuM482g8YCFBt2KuzjlvbQZGhzyozxhQjJvgJkeleH6C6gbr I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AioBAFvYvk2tJXHB/2dsb2JhbACYFY4Jd6UgnAiGAASGDo0Nih4 X-IronPort-AV: E=Sophos;i="4.64,303,1301875200"; d="scan'208";a="284164607" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by sj-iport-4.cisco.com with ESMTP; 02 May 2011 16:16:34 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id p42GGXdR014891; Mon, 2 May 2011 16:16:33 GMT Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 2 May 2011 11:16:33 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 2 May 2011 11:16:32 -0500 Message-ID: In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C04905E0E@XMB-RCD-111.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] WG adoption of draft-asati-dhc-relay-agent-config-00 Thread-Index: AcvwvmvXzCHd+ukFSkSNyX8FCnzm+gYI7ONA References: <067E6CE33034954AAC05C9EC85E2577C04905E0E@XMB-RCD-111.cisco.com> From: "Bernie Volz (volz)" To: "Rajiv Asati (rajiva)" , "Ted Lemon" , "John Jason Brzozowski" X-OriginalArrivalTime: 02 May 2011 16:16:33.0445 (UTC) FILETIME=[4D9AAD50:01CC08E4] Cc: dhcwg@ietf.org, "Ralph Droms \(rdroms\)" Subject: Re: [dhcwg] WG adoption of draft-asati-dhc-relay-agent-config-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: Mon, 02 May 2011 16:16:35 -0000 Where does this one stand? I wasn't at the meeting and this is a bit 'late' but was just reviewing the minutes that Ted had uploaded. >From the draft and from the slides: http://tools.ietf.org/html/draft-asati-dhc-relay-agent-config-00 http://www.ietf.org/proceedings/80/slides/dhc-9.pdf I don't really understand what this is all about and there really is very little here to go on. I must be missing something basic? This document defines a new option (which contains suboptions of WHAT?) and one suboption (which contains what)? Perahps figure 2 was supposed was not supposed to be an example (Subopt X not 1)? Seems silly to have a document which defines a new option to contain suboptions but no suboptions are defined? If this suboption space is elsewhere, can that document be referenced? Perhaps the these suboptions are the normal DHCPv4 options except they are passed to the relay? But nothing in the document makes this clear to me. The appendix discusses applicability to MPLS IP/VPN but there is nothing here to give us much guidance on what suboptions might exist. I would guess that this might contain the following potential data: The PE configuration information, in RFC4364 environment, may contain one or more of the following - - IP address and subnet for PE-CE interface - VRF Configuration (RD, RT etc.) - Other PE-CE Interface configuration (description, vrf mapping etc.) - Selected Routing Protocol instance (for the CE) - Neighbor and ASN information in case of BGP or EIGRP - Security, QoS information etc. (for the CE) There is already a work in progress on the VRF issue (see Kim Kinnear's draft-ietf-dhc-vpn-option-13 document which is about to be respun and is in IESG evaluation). So, it is rather difficult from the information available to give an opinion on this document. Perhaps more details were provided verbally at the DHC WG meeting, but that technically doesn't count (??) if it never makes it to the mailing list. Thus, I would not support this as a DHC WG work item until the draft is more flushed out and provides concrete information on what this is all about (such as defining some suboptions). - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Rajiv Asati (rajiva) Sent: Sunday, April 03, 2011 7:02 AM To: Ted Lemon; John Jason Brzozowski Cc: dhcwg@ietf.org Subject: [dhcwg] WG adoption of draft-asati-dhc-relay-agent-config-00 Given the positive feedback during the WG meeting on Thu, the authors would like to request the WG adoption of draft-asati-dhc-relay-agent-config-00. Thanks. Cheers, Rajiv =20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From suresh.krishnan@ericsson.com Fri May 6 15:41:41 2011 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 75C43E0719 for ; Fri, 6 May 2011 15:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.313 X-Spam-Level: X-Spam-Status: No, score=-105.313 tagged_above=-999 required=5 tests=[AWL=1.286, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JUzBoumPvSpF for ; Fri, 6 May 2011 15:41:40 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id AFD79E069B for ; Fri, 6 May 2011 15:41:40 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p46Mfdsx015833; Fri, 6 May 2011 17:41:40 -0500 Received: from [142.133.10.107] (147.117.20.213) by eusaamw0707.eamcs.ericsson.se (147.117.20.92) with Microsoft SMTP Server id 8.3.137.0; Fri, 6 May 2011 18:41:33 -0400 Message-ID: <4DC4786E.9070607@ericsson.com> Date: Fri, 6 May 2011 18:38:38 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: Ted Lemon References: <4A352640-DF7D-47F9-9D66-5AA41ACECBF6@nominum.com> In-Reply-To: <4A352640-DF7D-47F9-9D66-5AA41ACECBF6@nominum.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] Call for adoption: draft-xia-dhc-host-gen-id-04 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, 06 May 2011 22:41:41 -0000 Hi Ted, I have read the draft and I am supportive of the problem this draft is trying to solve (i.e. allow host generated IIDs). But, the mechanism proposed in the draft is a bit unclear for me to say whether this is the best way to solve the solution or not. In particular, the semantics of the IA_PA are not detailed very well. e.g. How exactly is this different from an IA_PD with a 64 bit prefix? Can a prefix inside a IA_PA be shared across multiple clients etc. Thanks Suresh 2011/4/25, Ted Lemon : > The working group discussed this draft in Prague and there was interest in > taking on the work. The draft is an attempt to solve the problem of how to > use CGAs and other host-generated addresses with DHCP. If you are in favor > of taking on this work, please let us know. If you think this is work the > working group should not do, please let us know. If you think the draft > doesn't adequately address the problem at present, please get involved. > > I will evaluate the working group consensus on adopting this work on Friday, > May 6. > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From internet-drafts@ietf.org Sun May 8 18:57:17 2011 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 B4B01E0796; Sun, 8 May 2011 18:57:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PzrRJhNGM6tL; Sun, 8 May 2011 18:57:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4995EE069A; Sun, 8 May 2011 18:57:17 -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: 3.53 Message-ID: <20110509015717.27127.5141.idtracker@ietfa.amsl.com> Date: Sun, 08 May 2011 18:57:17 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-relay-supplied-options-05.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, 09 May 2011 01:57:17 -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 : Relay-Supplied DHCP Options Author(s) : Ted Lemon Qin Wu Filename : draft-ietf-dhc-dhcpv6-relay-supplied-options-05.txt Pages : 8 Date : 2011-05-08 This document describes a mechanism whereby a DHCPv6 relay agent can provide options to a DHCPv6 server that the DHCPv6 server can then provide to the DHCPv6 client in certain restricted cases where this is necessary. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-relay-supplied-op= tions-05.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-relay-supplied-opt= ions-05.txt From jiangsheng@huawei.com Sun May 8 20:05:19 2011 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 90E35E0701 for ; Sun, 8 May 2011 20:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pFHVZWAMzTR7 for ; Sun, 8 May 2011 20:05:18 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 82DA9E06A3 for ; Sun, 8 May 2011 20:05:18 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKW006V8R8K34@szxga03-in.huawei.com> for dhcwg@ietf.org; Mon, 09 May 2011 11:05:09 +0800 (CST) Received: from szxeml208-edg.china.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKW00BH0R8KKX@szxga03-in.huawei.com> for dhcwg@ietf.org; Mon, 09 May 2011 11:05:08 +0800 (CST) Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 09 May 2011 11:05:08 +0800 Received: from SZXEML504-MBS.china.huawei.com ([169.254.4.122]) by SZXEML401-HUB.china.huawei.com ([10.82.67.31]) with mapi id 14.01.0270.001; Mon, 09 May 2011 11:05:08 +0800 Date: Mon, 09 May 2011 03:05:07 +0000 From: Jiangsheng In-reply-to: <4DC4786E.9070607@ericsson.com> X-Originating-IP: [10.110.98.37] To: Suresh Krishnan , Ted Lemon Message-id: <5D36713D8A4E7348A7E10DF7437A4B92835398@SZXEML504-MBS.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-GB, zh-CN, en-US Thread-topic: [dhcwg] Call for adoption: draft-xia-dhc-host-gen-id-04 Thread-index: AQHMDD7O0UdRW5N5Wk6UhUPUFsZfC5SDv4iw X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <4A352640-DF7D-47F9-9D66-5AA41ACECBF6@nominum.com> <4DC4786E.9070607@ericsson.com> Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] Call for adoption: draft-xia-dhc-host-gen-id-04 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, 09 May 2011 03:05:19 -0000 Hi, Suresh, Thanks for your read and support. In principle, the format of IA_PA is the same with IA_PD except for Option code. The different is on the semantics and usage model. The IA_PD option is to delegate prefix to a routable device for itself use only. The IA_PA option is to assign/notify a prefix to a host device. The prefix inside an IA_PA is shared across many clients. We will make this clear in next version. Thanks for pointing this out. Best regards, Sheng > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf > Of Suresh Krishnan > Sent: Saturday, May 07, 2011 6:39 AM > To: Ted Lemon > Cc: dhcwg@ietf.org WG > Subject: Re: [dhcwg] Call for adoption: draft-xia-dhc-host-gen-id-04 > > Hi Ted, > I have read the draft and I am supportive of the problem this draft > is trying to solve (i.e. allow host generated IIDs). But, the mechanism > proposed in the draft is a bit unclear for me to say whether this is > the > best way to solve the solution or not. In particular, the semantics of > the IA_PA are not detailed very well. e.g. How exactly is this > different > from an IA_PD with a 64 bit prefix? Can a prefix inside a IA_PA be > shared across multiple clients etc. > > Thanks > Suresh > > 2011/4/25, Ted Lemon : > > The working group discussed this draft in Prague and there was > interest in > > taking on the work. The draft is an attempt to solve the problem of > how to > > use CGAs and other host-generated addresses with DHCP. If you are > in favor > > of taking on this work, please let us know. If you think this is > work the > > working group should not do, please let us know. If you think the > draft > > doesn't adequately address the problem at present, please get > involved. > > > > I will evaluate the working group consensus on adopting this work on > Friday, > > May 6. > > > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www.ietf.org/mailman/listinfo/dhcwg > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From internet-drafts@ietf.org Sun May 8 20:49:02 2011 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 26736E06F6; Sun, 8 May 2011 20:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GaFRHqvx2Pj5; Sun, 8 May 2011 20:49:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33936E067A; Sun, 8 May 2011 20:49: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: 3.53 Message-ID: <20110509034901.16816.63397.idtracker@ietfa.amsl.com> Date: Sun, 08 May 2011 20:49:01 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-relay-supplied-options-06.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, 09 May 2011 03:49: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 : Relay-Supplied DHCP Options Author(s) : Ted Lemon Qin Wu Filename : draft-ietf-dhc-dhcpv6-relay-supplied-options-06.txt Pages : 8 Date : 2011-05-08 This document describes a mechanism whereby a DHCPv6 relay agent can provide options to a DHCPv6 server that the DHCPv6 server can then provide to the DHCPv6 client in certain restricted cases where this is necessary. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-relay-supplied-op= tions-06.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-relay-supplied-opt= ions-06.txt From Internet-Drafts@ietf.org Mon May 9 09:30:12 2011 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 A3496E0867; Mon, 9 May 2011 09:30:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YtI3VlI1Q43X; Mon, 9 May 2011 09:30:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A632DE0868; Mon, 9 May 2011 09:30:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.53 Message-ID: <20110509163003.30973.8536.idtracker@ietfa.amsl.com> Date: Mon, 09 May 2011 09:30:03 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-vpn-option-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: Mon, 09 May 2011 16:30:12 -0000 --NextPart 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. Title : Virtual Subnet Selection Options for DHCPv4 and DHCPv6 Author(s) : K. Kinnear, et al Filename : draft-ietf-dhc-vpn-option-13.txt Pages : 25 Date : 2011-04-29 This memo defines a Virtual Subnet Selection (VSS) option for each of DHCPv4 and DHCPv6, and a VSS sub-option carried in the DHCPv4 relay- agent-information option. These are intended for use by DHCP clients, relay agents, and proxy clients in situations where VSS information needs to be passed to the DHCP server for proper address or prefix allocation to take place. For the DHCPv4 option and relay-agent-information sub-option, this memo documents existing usage as per RFC 3942 [RFC3942]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-vpn-option-13.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dhc-vpn-option-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-05-09092639.I-D@ietf.org> --NextPart-- From tomasz.mrugalski@gmail.com Mon May 9 14:07:57 2011 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 50182E0911 for ; Mon, 9 May 2011 14:07:57 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hciMDdA2fuCs for ; Mon, 9 May 2011 14:07:55 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 11A78E069C for ; Mon, 9 May 2011 14:07:54 -0700 (PDT) Received: by eye13 with SMTP id 13so2036833eye.31 for ; Mon, 09 May 2011 14:07:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=qmNBMakYOqUKK6jdQ5qKrCoDDpLgnit3VRMPBSAejxo=; b=RCj5RzDIuxB5mR8OK0e68U4m9RzKaNYcS/ZBuTPylYTq8gn215DFFvFIF6RxlmqMHr 5Ald43AqhW0+oPY1fr3ZwvlQnW6fB6BxTEj6uo4nTRddeUyqZ+BIiKtMDKt4IilvxmWw S1qL8fxg/yuBPabzdK3mZEkGlMpBRqLP9E3wg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=mD83n40eDp7GQ4MjvXj+oIXyuyREKniR0ubrv68muyTmpXmAez8MUmrRCFA3lTETfE LclI5B+R5xTpeGV3pncIS9zjnw1E5HOa0fONtgGQa3jYtKExOUhZ6ZeXcPUgI1Hl8Q/6 wX9+CB27EDO768VZ3rARrr2JJkTOVGaNai8Bk= Received: by 10.14.16.100 with SMTP id g76mr3473816eeg.168.1304975271997; Mon, 09 May 2011 14:07:51 -0700 (PDT) Received: from [10.0.0.100] (host-109-107-11-157.ip.jarsat.pl [109.107.11.157]) by mx.google.com with ESMTPS id 46sm3765212ees.11.2011.05.09.14.07.50 (version=SSLv3 cipher=OTHER); Mon, 09 May 2011 14:07:50 -0700 (PDT) Message-ID: <4DC8579E.7080606@gmail.com> Date: Mon, 09 May 2011 23:07:42 +0200 From: Tomasz Mrugalski User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: dhcwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [dhcwg] DHCPv6 Failover - volunteers needed 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, 09 May 2011 21:07:57 -0000 Dear group, DHCPv6 failover was mentioned a couple of times on mailing list and other places, but it looks like no real work started in that area. I'd like to change that. I'm looking for people, who would like to be involved in DHCPv6 failover work. Ted Lemon and John Brzozowski are supporting this effort. If you are interested, please respond to the list or contact me directly. My high level plan is to write DHCPv6 failover requirements document first. This will let us avoid problems encountered with v4 failover standardization attempts - it started as relatively simple draft, but people kept adding extra features and it became something else than originally envisaged. That would be very short document that would contain definitions and enumerate goals of this work, what is relevant and what is outside of scope. If you think that having such requirements list as a separate document is a bad idea, we could consider incorporating it into the main failover draft, but in my opinion having separate documents is cleaner and easier to maintain. Here are initial questions that we should consider, sometimes with my first proposed answers. 1. Primary goal is to define failover protocol, so rough failover definition is needed. DHCPv6 failover is an ability of one peer (DHCPv6 server) to continue serving leases provided by another peer, without affecting clients' connectivity. 2. Do we want high availability? 4. Do we want load balancing? 6. Should geographically distributed failover be taken into consideration? 3. If we want HA/LB/geo-failover, should it be defined in the core spec or as a separate document? Keeping them in single document can be easier in the beginning, but then can bloat the document quickly. 4. Should failover also cover prefix delegations or addresses only? My proposal is both address and prefixes. PD is a core feature of DHCPv6, so we can't pretend that it doesn't exist. PD is a must. 5. How many peers should this protocol support? My opinion is that 2 is enough. While having several peers would be great, the difficulty of synchronizing bigger number of peers than a pair may be very difficult. After we agree on answers to those questions, we may start thinking about how should the actual handover protocol will work. Two introductory questions for now: 6. Should we adopt DHCPv4 failover (http://tools.ietf.org/id/draft-ietf-dhc-failover-12.txt) as a starting point (or at least based on the same concept)? Note that this work started in 1997, but was eventually abandoned in 2003, so using the latest revision as a starting point may not be the best idea. 7. Significant part of the failover will be synchronization between peers, including transmitting selected/all leases. There is similar mechanism used in leasequery (RFC5007) and bulk leasequery (RFC5460). Do we want to reuse/extend that or define something new? Feel free to add other questions to the list. I'm looking forward to your comments and suggestions, Tomek Mrugalski ISC From tomasz.mrugalski@gmail.com Mon May 9 15:04:14 2011 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 6028CE08FF for ; Mon, 9 May 2011 15:04:14 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DWwSTmsb26vK for ; Mon, 9 May 2011 15:04:13 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6A510E0906 for ; Mon, 9 May 2011 15:04:13 -0700 (PDT) Received: by ewy19 with SMTP id 19so2045695ewy.31 for ; Mon, 09 May 2011 15:04:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:x-tagtoolbar-keys:content-type :content-transfer-encoding; bh=GIUu9gDC610kDrgje9eQnUC7yEQwdCWtEk5+jLVQQls=; b=Y4LaqorjoUzMKjWvW/lliU+KY2lCCvM8OfFFWIaXpDASUWSXCc7MxKjsthH970FXJh e13043LtKjB9+IvO7jxyZppi54HPRtLUrMO25Hd8wO2H88ld2eo6ScnbwGeHLhT/sl1K SzxlIiQ4ZvwXnV/qFKpXJE1AxnHFrp5wG6/PM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-tagtoolbar-keys:content-type :content-transfer-encoding; b=xSSpE7ctHVTztlkU0ARflqhE/1M/nACr9igpljNl4AaZ+/5IN3uvKSPgEym/oNMSVb ntqkTHD9UvtlUm8FLrB7px3dTvHQuZynNcz830yl8mW9/MeA790yBu72U+AgjnZyPM2n iX7gsHsizmsukK9U+Wxd8JRJQshu8+ee/jEaI= Received: by 10.213.99.69 with SMTP id t5mr2485877ebn.103.1304978652139; Mon, 09 May 2011 15:04:12 -0700 (PDT) Received: from [10.0.0.100] (host-109-107-11-157.ip.jarsat.pl [109.107.11.157]) by mx.google.com with ESMTPS id s62sm3818579eea.10.2011.05.09.15.04.09 (version=SSLv3 cipher=OTHER); Mon, 09 May 2011 15:04:10 -0700 (PDT) Message-ID: <4DC864D1.8010101@gmail.com> Date: Tue, 10 May 2011 00:04:01 +0200 From: Tomasz Mrugalski User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: dhcwg@ietf.org References: <94200415-3C9D-4C61-88AB-42A6D0E11649@nominum.com> In-Reply-To: <94200415-3C9D-4C61-88AB-42A6D0E11649@nominum.com> X-TagToolbar-Keys: D20110510000401833 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-pd-exclude-01 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, 09 May 2011 22:04:14 -0000 On 19.04.2011 21:18, Ted Lemon wrote: > We had a last call on this prior to the Prague meeting, and there was > work done off list, but no responses on-list. If you support this > work, please indicate that you support it. If you oppose the work, > please provide suggestions, comments, or reasons why it's entirely a > bad idea. I read and support this draft. I know that it's way past dead-line, so feel free to ignore my comments. Here are my comments. If it is not too late, you could consider them: 1. Section 1: "single aggregatable route/prefix has to represents one customer" => remove "has to" or change represents to represent. 2. Section 4.1 "The requesting router MUST NOT assign the excluded prefix to any of its downstream interfaces.". Is this implicit suggestion that assigning excluded prefix to upstream interface is ok? That would be against RFC3633, Section 12.1 that forbids that. This is probably ok, but then "updates: 3633" should be added to the preamble (and possibly a simple clarification). However, if the excluded prefix is handled in some different way (like SLAAC), then it is ok in current form. 3. Section 4.2 "The OPTION_PD_EXCLUDE option MUST be located before the possible Status Code option in the IAprefix-options field." Why forcing to use specific order? DHCPv6 does not impose any restrictions regarding sequence, in which options appear in a message or within other options. There's good reason for that - implementations may keep the options in structures other than simple lists or vector, like hash tables. Enforcing any specific order would be troublesome in that case. I propose to remove this sentence. 4. Section 5.1 My understanding was that requesting router is supposed to include PD_EXCLUDE in ORO in SOLICIT, REQUEST, RENEW, REBIND and CONFIRM. Yet, there is only Solicit message mentioned in the first sentence of 5.1. Remaining message types should probably be mentioned as well. 5. PD_EXCLUDE option is going to be delivered in IAPREFIX that is located in IA_PD (not in the message options field), but draft says that requesting router should request PD_EXCLUDE in ORO placed in message options field. Wouldn't it be more appropriate to put second instance of ORO (with PD_EXCLUDE code) in IA_PD sent by requesting router? You may consider reading draft-mrugalski-dhc-dhcpv6-suboptions and follow its suggestions, if you that they are reasonable. Hope that helps, Tomek Mrugalski ISC From mellon@fugue.com Mon May 9 21:21:22 2011 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 23C78E070B for ; Mon, 9 May 2011 21:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ncHit4pBLliN for ; Mon, 9 May 2011 21:21:21 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id B9608E06E2 for ; Mon, 9 May 2011 21:21:21 -0700 (PDT) Received: from [10.1.10.17] (173-162-214-218-NewEngland.hfc.comcastbusiness.net [173.162.214.218]) by toccata.fugue.com (Postfix) with ESMTPSA id 5A5E234E446B; Tue, 10 May 2011 00:21:52 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1222) Content-Type: text/plain; charset=iso-8859-1 From: Ted Lemon In-Reply-To: Date: Tue, 10 May 2011 00:21:17 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <71D013C5-38B6-453A-A505-CE30542545AC@fugue.com> References: <2A6D79FD-346C-4282-88E0-51AC68CC586C@fugue.com> To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Mailer: Apple Mail (2.1222) Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] Minutes from IETF 80 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, 10 May 2011 04:21:22 -0000 On May 3, 2011, at 8:26 AM, R=E9mi Despr=E9s wrote: > "Ted: You mashed together options, that will introduce complexity. > Better to use separate options. > R=E9mi Despr=E9s: That's not a problem to change it. > Ted: Also, you used bitmasks. Generally it's better not to do that. > R=E9mi: Also no problem to change it." Done. I put this in a week ago, but only just now verified that it had = propagated. From Ted.Lemon@nominum.com Mon May 9 21:24:58 2011 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 D089EE06B7 for ; Mon, 9 May 2011 21:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L7ZSXkREGenY for ; Mon, 9 May 2011 21:24:58 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id 06330E066E for ; Mon, 9 May 2011 21:24:57 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKTci+GdrS/Sayl/Q+hA/IGB27ZE9Rtg+9@postini.com; Mon, 09 May 2011 21:24:58 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 BE6A91B8628 for ; Mon, 9 May 2011 21:24:56 -0700 (PDT) Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id B2D4A190058; Mon, 9 May 2011 21:24:56 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from vpna-148.vpn.nominum.com (64.89.227.148) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 9 May 2011 21:24:56 -0700 MIME-Version: 1.0 (Apple Message framework v1222) Content-Type: text/plain; charset="us-ascii" From: Ted Lemon In-Reply-To: <4DC864D1.8010101@gmail.com> Date: Tue, 10 May 2011 00:24:52 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <94200415-3C9D-4C61-88AB-42A6D0E11649@nominum.com> <4DC864D1.8010101@gmail.com> To: Tomasz Mrugalski X-Mailer: Apple Mail (2.1222) Cc: dhcwg@ietf.org Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-pd-exclude-01 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, 10 May 2011 04:24:58 -0000 On May 9, 2011, at 6:04 PM, Tomasz Mrugalski wrote: > I know that it's way past dead-line, so feel free to ignore my = comments. These are good comments. I would like to see them addressed, if the = authors would be so kind. From mellon@fugue.com Tue May 10 19:33:20 2011 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 9878EE06CE for ; Tue, 10 May 2011 19:33:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UKPbv0P2G-1J for ; Tue, 10 May 2011 19:33:20 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 35E43E06A6 for ; Tue, 10 May 2011 19:33:20 -0700 (PDT) Received: from [10.1.10.17] (173-162-214-218-NewEngland.hfc.comcastbusiness.net [173.162.214.218]) by toccata.fugue.com (Postfix) with ESMTPSA id 309B634E4251 for ; Tue, 10 May 2011 22:33:52 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1222) From: Ted Lemon In-Reply-To: <4A352640-DF7D-47F9-9D66-5AA41ACECBF6@nominum.com> Date: Tue, 10 May 2011 22:33:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <56162D1F-D58B-45A5-B8E5-E8335B11E380@fugue.com> References: <4A352640-DF7D-47F9-9D66-5AA41ACECBF6@nominum.com> To: "dhcwg@ietf.org WG" X-Mailer: Apple Mail (2.1222) Subject: Re: [dhcwg] Call for adoption: draft-xia-dhc-host-gen-id-04 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, 11 May 2011 02:33:20 -0000 On Apr 25, 2011, at 1:31 AM, Ted Lemon wrote: > I will evaluate the working group consensus on adopting this work on = Friday, May 6. The working group consensus seems to be in favor of this document. We = will adopt it as a working group item. Several good suggestions were = made; I hope that the people who participated in this call for adoption = will continue to follow the document and help the editors to improve it. From Ted.Lemon@nominum.com Tue May 10 19:41:02 2011 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 9B073E06DB for ; Tue, 10 May 2011 19:41:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104 X-Spam-Level: X-Spam-Status: No, score=-104 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uEl5eF-0z95X for ; Tue, 10 May 2011 19:41:02 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id E23DBE06CE for ; Tue, 10 May 2011 19:41:01 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKTcn3PaNZEOIX1qUXRTIh06u7FPhSJG8V@postini.com; Tue, 10 May 2011 19:41:02 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 C70CF1B8738 for ; Tue, 10 May 2011 19:41:00 -0700 (PDT) Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id B755719005D; Tue, 10 May 2011 19:41:00 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from [10.1.10.17] (173.162.214.218) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 10 May 2011 19:41:00 -0700 MIME-Version: 1.0 (Apple Message framework v1222) Content-Type: text/plain; charset="us-ascii" From: Ted Lemon In-Reply-To: Date: Tue, 10 May 2011 22:40:57 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <9105F293-1C25-4546-85B0-CF1E1A035CD9@nominum.com> References: <067E6CE33034954AAC05C9EC85E2577C04905E0E@XMB-RCD-111.cisco.com> To: Bernie Volz X-Mailer: Apple Mail (2.1222) Cc: dhcwg@ietf.org, "Ralph Droms \(rdroms\)" , "Rajiv Asati \(rajiva\)" Subject: Re: [dhcwg] WG adoption of draft-asati-dhc-relay-agent-config-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: Wed, 11 May 2011 02:41:02 -0000 On May 2, 2011, at 12:16 PM, Bernie Volz (volz) wrote: > So, it is rather difficult from the information available to give an > opinion on this document. Perhaps more details were provided verbally = at > the DHC WG meeting, but that technically doesn't count (??) if it = never > makes it to the mailing list. >=20 > Thus, I would not support this as a DHC WG work item until the draft = is > more flushed out and provides concrete information on what this is all > about (such as defining some suboptions). I can't speak for the authors here, but I think the intent was to = separate the transport from the payload: defining a way to carry options = to the relay agent to configure it, and then subsequently defining = options to be used for configuring it. Perhaps the authors can speak = to this point. There were a number of suggestions for how to improve the mechanism = suggested in the meeting, and there seemed to be interest in the option. = I will admit that in simply reading the draft, it does seem like it's = not actually doing anything, so I understand where your comments are = coming from. From Ted.Lemon@nominum.com Tue May 10 19:53:16 2011 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 9A274E06E6 for ; Tue, 10 May 2011 19:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104 X-Spam-Level: X-Spam-Status: No, score=-104 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kEddYufhkzbH for ; Tue, 10 May 2011 19:53:16 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id 26511E06CE for ; Tue, 10 May 2011 19:52:21 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKTcn55Phv+WZutuDOAFtkoTCf+5H8gRHJ@postini.com; Tue, 10 May 2011 19:52:21 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 8DA3E1B8738 for ; Tue, 10 May 2011 19:52:20 -0700 (PDT) Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 78D1E19005D; Tue, 10 May 2011 19:52:20 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from [10.1.10.17] (173.162.214.218) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 10 May 2011 19:52:20 -0700 From: Ted Lemon Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 10 May 2011 22:52:18 -0400 Message-ID: <8BDE4E5D-6CB9-4DA2-8F29-44471D5DF954@nominum.com> To: "dhcwg@ietf.org WG" MIME-Version: 1.0 (Apple Message framework v1222) X-Mailer: Apple Mail (2.1222) Cc: Ralph Droms , "Rajiv Asati \(rajiva\)" Subject: [dhcwg] Call for adoption: draft-asati-dhc-relay-agent-config-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: Wed, 11 May 2011 02:53:16 -0000 This document was presented in the DHC working group meeting in Prague. = There was significant interest in the work, and the sense of the room = was that there was consensus to adopt. Bernie Volz has raised some = concerns on the mailing list, and doesn't currently agree with the = consensus. I'd like to see some discussion about this on the list. = Please let's not just vote on this--in particular, I ask the authors to = respond to the questions Bernie raised. However, if you have an = opinion on the usefulness of this proposal, please do indicate on the = mailing list whether you support adopting this work, or oppose adopting = it, even if you don't have anything to add to the discussion. I will evaluate the consensus on Wednesday, May 25, assuming that there = has been discussion on the matter, and that it's come to some = resolution. Please comment before that time. If there is no = discussion, the working group will not adopt the work as it stands. From mellon@fugue.com Tue May 10 19:58:22 2011 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 09D0CE070A for ; Tue, 10 May 2011 19:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jOhVCZyVwXCo for ; Tue, 10 May 2011 19:58:21 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 95588E06E3 for ; Tue, 10 May 2011 19:58:21 -0700 (PDT) Received: from [10.1.10.17] (173-162-214-218-NewEngland.hfc.comcastbusiness.net [173.162.214.218]) by toccata.fugue.com (Postfix) with ESMTPSA id 01A0834E445C for ; Tue, 10 May 2011 22:58:53 -0400 (EDT) From: Ted Lemon Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 10 May 2011 22:58:17 -0400 Message-Id: To: "dhcwg@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1222) X-Mailer: Apple Mail (2.1222) Subject: [dhcwg] Call for adoption: draft-guo-softwire-6rd-ipv6-config-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, 11 May 2011 02:58:22 -0000 This document proposes a mechanism for configuring the IPv6 stack over a = 6RD tunnel using DHCPv6. It was presented at the meeting in Prague. = This is an interesting problem because the DHCPv6 spec prevents DHCP = clients from configuring themselves directly over tunnels. Two solutions = were suggested: either relax some restrictions in RFC3315 with regard to = source addresses, or else use a DHCPv6 relay agent to forward the packet = over the tunnel. The consensus of the room was to adopt the work; = although this is related to 6RD, it is a DHCP-specific draft, so there = was agreement that the DHC working group is the right place for the = work. If you agree that the working group should do this work, please indicate = that agreement on the list; likewise if you disagree. If you have no = opinion, there is no need to say so. We will evaluate the consensus on Wednesday, May 25. Please get your = comments in before that time. From leaf.y.yeh@huawei.com Tue May 10 20:50:43 2011 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 39C17E06E6 for ; Tue, 10 May 2011 20:50:43 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JMpEQTu57BcE for ; Tue, 10 May 2011 20:50:42 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 845E6E06E3 for ; Tue, 10 May 2011 20:50:42 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LL0002XEINF2A@szxga04-in.huawei.com> for dhcwg@ietf.org; Wed, 11 May 2011 11:50:03 +0800 (CST) Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LL000BXSINFP8@szxga04-in.huawei.com> for dhcwg@ietf.org; Wed, 11 May 2011 11:50:03 +0800 (CST) Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 11 May 2011 11:50:00 +0800 Received: from SZXEML514-MBS.china.huawei.com ([169.254.6.159]) by SZXEML401-HUB.china.huawei.com ([10.82.67.31]) with mapi id 14.01.0270.001; Wed, 11 May 2011 11:50:02 +0800 Date: Wed, 11 May 2011 03:50:01 +0000 From: Leaf yeh In-reply-to: <9105F293-1C25-4546-85B0-CF1E1A035CD9@nominum.com> X-Originating-IP: [10.70.39.133] To: "dhcwg@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=Windows-1252 Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: [dhcwg] WG adoption of draft-asati-dhc-relay-agent-config-00 Thread-index: AcvwvmvXzCHd+ukFSkSNyX8FCnzm+gYI7ONAAZfrWYAAEvCUcA== X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <067E6CE33034954AAC05C9EC85E2577C04905E0E@XMB-RCD-111.cisco.com> <9105F293-1C25-4546-85B0-CF1E1A035CD9@nominum.com> Cc: Ted Lemon , Bernie Volz Subject: Re: [dhcwg] WG adoption of draft-asati-dhc-relay-agent-config-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: Wed, 11 May 2011 03:50:43 -0000 Ted - I will admit that in simply reading the draft, it does seem like it's not actually doing anything, ... Got the same feeling or question as Bernie's after the quick review. Can't say yes or hum till now. -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Ted Lemon Sent: Wednesday, May 11, 2011 10:41 AM To: Bernie Volz Cc: dhcwg@ietf.org; Ralph Droms (rdroms); Rajiv Asati (rajiva) Subject: Re: [dhcwg] WG adoption of draft-asati-dhc-relay-agent-config-00 On May 2, 2011, at 12:16 PM, Bernie Volz (volz) wrote: > So, it is rather difficult from the information available to give an > opinion on this document. Perhaps more details were provided verbally at > the DHC WG meeting, but that technically doesn't count (??) if it never > makes it to the mailing list. > > Thus, I would not support this as a DHC WG work item until the draft is > more flushed out and provides concrete information on what this is all > about (such as defining some suboptions). I can't speak for the authors here, but I think the intent was to separate the transport from the payload: defining a way to carry options to the relay agent to configure it, and then subsequently defining options to be used for configuring it. Perhaps the authors can speak to this point. There were a number of suggestions for how to improve the mechanism suggested in the meeting, and there seemed to be interest in the option. I will admit that in simply reading the draft, it does seem like it's not actually doing anything, so I understand where your comments are coming from. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From leaf.y.yeh@huawei.com Tue May 10 20:53:59 2011 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 39BD6E0722 for ; Tue, 10 May 2011 20:53:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NYi62j-m-MZl for ; Tue, 10 May 2011 20:53:58 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 9E6B7E06E3 for ; Tue, 10 May 2011 20:53:58 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LL0007WWIRC4J@szxga05-in.huawei.com> for dhcwg@ietf.org; Wed, 11 May 2011 11:52:24 +0800 (CST) Received: from szxeml207-edg.china.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LL000JTIIRB2Q@szxga05-in.huawei.com> for dhcwg@ietf.org; Wed, 11 May 2011 11:52:24 +0800 (CST) Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 11 May 2011 11:52:20 +0800 Received: from SZXEML514-MBS.china.huawei.com ([169.254.6.159]) by SZXEML402-HUB.china.huawei.com ([10.82.67.32]) with mapi id 14.01.0270.001; Wed, 11 May 2011 11:52:23 +0800 Date: Wed, 11 May 2011 03:52:22 +0000 From: Leaf yeh In-reply-to: <8BDE4E5D-6CB9-4DA2-8F29-44471D5DF954@nominum.com> X-Originating-IP: [10.70.39.133] To: "dhcwg@ietf.org WG" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=Windows-1252 Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: [dhcwg] Call for adoption: draft-asati-dhc-relay-agent-config-00 Thread-index: AQHMD4cWfb7ru1RGy0Co18Gu5ujBh5SG+DCQ X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <8BDE4E5D-6CB9-4DA2-8F29-44471D5DF954@nominum.com> Subject: Re: [dhcwg] Call for adoption: draft-asati-dhc-relay-agent-config-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: Wed, 11 May 2011 03:53:59 -0000 Ted - I'd like to see some discussion about this on the list. Please let's not just vote on this--in particular, I ask the authors to respond to the questions Bernie raised. Raised 1 more Question of Clarification at Apr. 25th in the mailing list, but no reply from the author yet. -1 Best Regards, Leaf -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Ted Lemon Sent: Wednesday, May 11, 2011 10:52 AM To: dhcwg@ietf.org WG Cc: Ralph Droms; Rajiv Asati (rajiva) Subject: [dhcwg] Call for adoption: draft-asati-dhc-relay-agent-config-00 This document was presented in the DHC working group meeting in Prague. There was significant interest in the work, and the sense of the room was that there was consensus to adopt. Bernie Volz has raised some concerns on the mailing list, and doesn't currently agree with the consensus. I'd like to see some discussion about this on the list. Please let's not just vote on this--in particular, I ask the authors to respond to the questions Bernie raised. However, if you have an opinion on the usefulness of this proposal, please do indicate on the mailing list whether you support adopting this work, or oppose adopting it, even if you don't have anything to add to the discussion. I will evaluate the consensus on Wednesday, May 25, assuming that there has been discussion on the matter, and that it's come to some resolution. Please comment before that time. If there is no discussion, the working group will not adopt the work as it stands. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From volz@cisco.com Tue May 10 23:50:40 2011 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 E57A8E066A for ; Tue, 10 May 2011 23:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32w0LJHToCk8 for ; Tue, 10 May 2011 23:50:34 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA62E0665 for ; Tue, 10 May 2011 23:50:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=9662; q=dns/txt; s=iport; t=1305096634; x=1306306234; h=mime-version:subject:date:message-id:from:to:cc; bh=ycxZZab9EedVttp9vP4hm6QRwG7ii3/2WqC9wgmBIQ0=; b=fEclb4i+t4oYhLIPPe9WGb+l4SKSCfrFyHNOJM+dR61vX3MS4egCuPKA H8oAERegeoZTRIGZP5VA9cwagRqJ3ZdX3+jquunPDmvngdOPRWMvF2gdl /bRUSsvA9w+aPEIRD2LJZwA+9hs6oWzYeVs4+47fjEOr833uwQEQjAlDz I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAIEwyk2tJV2Z/2dsb2JhbACCZKMld6h7ng6GEASGQ41dik8 X-IronPort-AV: E=Sophos;i="4.64,350,1301875200"; d="scan'208,217";a="445496191" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by sj-iport-1.cisco.com with ESMTP; 11 May 2011 06:50:33 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p4B6oXK2021173 for ; Wed, 11 May 2011 06:50:33 GMT Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 May 2011 01:50:33 -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_01CC0FA7.B9783B2C" Date: Wed, 11 May 2011 01:50:31 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FYI - A note regarding DHCPv6 from Interop 2011 Thread-Index: AcwPp7iTxLJMabhYQrKvdxna/otGHA== From: "Bernie Volz (volz)" To: "Ralph Droms (rdroms)" , X-OriginalArrivalTime: 11 May 2011 06:50:33.0209 (UTC) FILETIME=[B971A690:01CC0FA7] Cc: "Kim Kinnear \(kkinnear\)" Subject: [dhcwg] FYI - A note regarding DHCPv6 from Interop 2011 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, 11 May 2011 06:50:41 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC0FA7.B9783B2C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have been at Interop 2011 working as part of the InteropNet team as Cisco is a sponsor/provider of the network. =20 The one DHCPv6 issue that came up, which isn't new, is that there were incidences of duplicate IPv6 address assigned from the DHCP Server (Cisco Network Registrar) - this was obvious from the DHCPv6 DECLINE messages which like DHCPv4 DHCPDECLINEs should generally NOT occur. This was because one of the vendors that supplied PCs for A/V needs, attendee use, and conference operations had cloned a Windows 7 machine and not wiped out the Dhcpv6DUID registry key. (I suspect more than one vendor might have been involved given the number of different DUIDs but it could also have been different images for different system types.) =20 I suspect that this will be a reoccurring issue and I figured it was worth highlighting, at least to the DHC WG mailing list. The more people that know about this requirement, the better - both in reducing its occurrence in the first place, and understanding what it is and how to resolve it should It happen. =20 It was pretty easy to resolve on a machine-by-machine basis (in some cases, IPv6 was disabled; in others the registry key was deleted and machine rebooted). =20 Incidentally, between 33% and 40% of the DHCPv4 devices (visitors, exhibitors, conference operations) likely support DHCPv6 which was, to me at least, a surprisingly high percentage (this figure is based on the percentage of active leases - DHCPv6 count / DHCPv4 count). But this is good news for DHCPv6 and IPv6 in general. =20 - Bernie ------_=_NextPart_001_01CC0FA7.B9783B2C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have = been at Interop 2011 working as part of the InteropNet team as Cisco is = a sponsor/provider of the network.

 

The one = DHCPv6 issue that came up, which isn’t new, is that there were = incidences of duplicate IPv6 address assigned from the DHCP Server = (Cisco Network Registrar) – this was obvious from the DHCPv6 = DECLINE messages which like DHCPv4 DHCPDECLINEs should generally NOT = occur. This was because one of the vendors that supplied PCs for A/V = needs, attendee use, and conference operations had cloned a Windows 7 = machine and not wiped out the Dhcpv6DUID registry key. (I suspect more = than one vendor might have been involved given the number of different = DUIDs but it could also have been different images for different system = types.)

 

I suspect that this will be a reoccurring issue and I = figured it was worth highlighting, at least to the DHC WG mailing list. = The more people that know about this requirement, the better – = both in reducing its occurrence in the first place, and understanding = what it is and how to resolve it should It happen.

 

It was = pretty easy to resolve on a machine-by-machine basis (in some cases, = IPv6 was disabled; in others the registry key was deleted and machine = rebooted).

 

Incidentally, between 33% and 40% of the DHCPv4 = devices (visitors, exhibitors, conference operations) likely support = DHCPv6 which was, to me at least, a surprisingly high percentage (this = figure is based on the percentage of active leases – DHCPv6 count = / DHCPv4 count). But this is good news for DHCPv6 and IPv6 in = general.

 

-          = Bernie

------_=_NextPart_001_01CC0FA7.B9783B2C-- From ichiroumakino@gmail.com Wed May 11 00:16:26 2011 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 6FAC2E077D for ; Wed, 11 May 2011 00:16:26 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t2iEo9FaHR7x for ; Wed, 11 May 2011 00:16:25 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 30FBEE077A for ; Wed, 11 May 2011 00:16:25 -0700 (PDT) Received: by eye13 with SMTP id 13so78368eye.31 for ; Wed, 11 May 2011 00:16:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=NrSzkNuXZna3KOye5gLT9iZlWmMA+xC9oBe8a0h6Xg8=; b=VSgegVfmMjL1Idn4ldcuX4hOVmiWIgEf6MulmEDUtSK7r+6Pa8rJPSN/A7wXrgGx/H kZYrcAiEo5DAZaEO/qFz25jVXWx5MEpsyRpzjzrYm8uebQ11JejFyKgcJCalI9wXz4hB qTFW2SY0dbm+4L+va/5G9Dk2bGsIr6mLtUk3U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=FJToaUM59QYDKKbv83UWG/tn88v+4q3/QMBi0AVqpP5QID34qB9Yzkhyc83WfnlCoE Lkpq2jtAxmCS5/+zFND+lME7PPfNdYuoRVL5eJTroiDW3MAIa1dhjzsCHC+m7YAGpCV6 9pEdJ430SzQkRiK8q2sbBlW4uc2BJ8EiJ6Oks= Received: by 10.14.4.209 with SMTP id 57mr4077493eej.87.1305098182274; Wed, 11 May 2011 00:16:22 -0700 (PDT) Received: from gomlefisk.cisco.com (184.84-48-218.nextgentel.com [84.48.218.184]) by mx.google.com with ESMTPS id s1sm4858697ees.17.2011.05.11.00.16.20 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 11 May 2011 00:16:20 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: <4DC864D1.8010101@gmail.com> Date: Wed, 11 May 2011 09:16:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <969A86F7-D2B4-482D-8E2F-A845DB53D09F@employees.org> References: <94200415-3C9D-4C61-88AB-42A6D0E11649@nominum.com> <4DC864D1.8010101@gmail.com> To: Tomasz Mrugalski X-Mailer: Apple Mail (2.1084) Cc: "dhcwg@ietf.orgWG WG" , Jouni Korhonen Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-pd-exclude-01 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, 11 May 2011 07:16:26 -0000 Tomek, thanks for good comments! >> We had a last call on this prior to the Prague meeting, and there was >> work done off list, but no responses on-list. If you support this >> work, please indicate that you support it. If you oppose the work, >> please provide suggestions, comments, or reasons why it's entirely a >> bad idea. > I read and support this draft. >=20 > I know that it's way past dead-line, so feel free to ignore my = comments. >=20 > Here are my comments. If it is not too late, you could consider them: >=20 > 1. Section 1: > "single aggregatable route/prefix has to represents one customer" > =3D> remove "has to" or change represents to represent. agree. > 2. Section 4.1 > "The requesting router MUST NOT assign the excluded prefix to any of = its > downstream interfaces.". Is this implicit suggestion that assigning > excluded prefix to upstream interface is ok? That would be against > RFC3633, Section 12.1 that forbids that. This is probably ok, but then > "updates: 3633" should be added to the preamble (and possibly a simple > clarification). However, if the excluded prefix is handled in some > different way (like SLAAC), then it is ok in current form. we are basically trying to say that the excluded prefix is not delegated = to the requesting router. that means the requesting router has no 'ownership' of that prefix and = cannot assign it to any interface. obviously the delegating router can advertise that prefix in an RA and = then the requesting router can use SLAAC to configure an address out of = the prefix. do you think this needs clarification, if so suggested text? > 3. Section 4.2 > "The OPTION_PD_EXCLUDE option MUST be located before the possible = Status > Code option in the IAprefix-options field." Why forcing to use = specific > order? DHCPv6 does not impose any restrictions regarding sequence, in > which options appear in a message or within other options. There's = good > reason for that - implementations may keep the options in structures > other than simple lists or vector, like hash tables. Enforcing any > specific order would be troublesome in that case. I propose to remove > this sentence. I tend to agree, what do my co-authors think? can't remember why we put this in the first place... > 4. Section 5.1 > My understanding was that requesting router is supposed to include > PD_EXCLUDE in ORO in SOLICIT, REQUEST, RENEW, REBIND and CONFIRM. Yet, > there is only Solicit message mentioned in the first sentence of 5.1. > Remaining message types should probably be mentioned as well. what about: If the requesting router implements the solution described in Section = 4.1 then the requesting router SHOULD include the OPTION_PD_EXCLUDE option = code in the OPTION_ORO option in DHCP messages as described in section 22.7 of RFC3315. > 5. PD_EXCLUDE option is going to be delivered in IAPREFIX that is > located in IA_PD (not in the message options field), but draft says = that > requesting router should request PD_EXCLUDE in ORO placed in message > options field. Wouldn't it be more appropriate to put second instance = of > ORO (with PD_EXCLUDE code) in IA_PD sent by requesting router? You may > consider reading draft-mrugalski-dhc-dhcpv6-suboptions and follow its > suggestions, if you that they are reasonable. good point, I wasn't aware of this. I also think including the ORO at = the correct option 'scope' is better. any objections to that? cheers, Ole= From john_brzozowski@cable.comcast.com Wed May 11 04:55:12 2011 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 7D395E06D6 for ; Wed, 11 May 2011 04:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.135 X-Spam-Level: X-Spam-Status: No, score=-101.135 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_54=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mwSnlH5PA9uE for ; Wed, 11 May 2011 04:55:11 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id BF60AE0746 for ; Wed, 11 May 2011 04:55:11 -0700 (PDT) Received: from ([24.40.55.41]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.37874524; Wed, 11 May 2011 05:59:09 -0600 Received: from PACDCEXMB01.cable.comcast.com ([fe80::3cf0:9cac:6c2a:7359]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%12]) with mapi id 14.01.0289.001; Wed, 11 May 2011 07:55:04 -0400 From: "Brzozowski, John" To: "Bernie Volz (volz)" , Ralph Droms , dhc WG Thread-Topic: [dhcwg] FYI - A note regarding DHCPv6 from Interop 2011 Thread-Index: AcwPp7iTxLJMabhYQrKvdxna/otGHAAKonoA Date: Wed, 11 May 2011 11:55:03 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 x-originating-ip: [147.191.125.12] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <3F3FE11C49AD72418E93D35A16F0B300@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Kim Kinnear Subject: Re: [dhcwg] FYI - A note regarding DHCPv6 from Interop 2011 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, 11 May 2011 11:55:12 -0000 Bernie, Are there any more details available, specifically what OSes or devices supported DHCPv6 and IPv6? Apologies for uninformed questions, I am not familiar with how Interop is run. Will they issue any sort of report or paper outlining the activities/testing? Thanks, John =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D John Jason Brzozowski Comcast Cable e) mailto:john_brzozowski@cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On 5/11/11 2:50 AM, "Bernie Volz (volz)" wrote: >I have been at Interop 2011 working as part of the InteropNet team as >Cisco is a sponsor/provider of the network. >=20 >The one DHCPv6 issue that came up, which isn=B9t new, is that there were >incidences of duplicate IPv6 address assigned from the DHCP Server (Cisco >Network Registrar) =AD this was obvious from the DHCPv6 DECLINE messages >which like DHCPv4 DHCPDECLINEs should generally NOT occur. This was >because one of the vendors that supplied PCs for A/V needs, attendee use, >and conference operations had cloned a Windows 7 machine and not wiped >out the Dhcpv6DUID registry key. (I suspect more than one vendor might >have been involved given the number of different DUIDs but it could also >have been different images for different system types.) >=20 >I suspect that this will be a reoccurring issue and I figured it was >worth highlighting, at least to the DHC WG mailing list. The more people >that know about this requirement, the better =AD both in reducing its >occurrence in the first place, and understanding what it is and how to >resolve it should It happen. >=20 >It was pretty easy to resolve on a machine-by-machine basis (in some >cases, IPv6 was disabled; in others the registry key was deleted and >machine rebooted). >=20 >Incidentally, between 33% and 40% of the DHCPv4 devices (visitors, >exhibitors, conference operations) likely support DHCPv6 which was, to me >at least, a surprisingly high percentage (this figure is based on the >percentage of active leases =AD DHCPv6 count / DHCPv4 count). But this is >good news for DHCPv6 and IPv6 in general. >=20 >- Bernie > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www.ietf.org/mailman/listinfo/dhcwg From Ted.Lemon@nominum.com Wed May 11 05:16:40 2011 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 5D59AE06D1 for ; Wed, 11 May 2011 05:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.3 X-Spam-Level: X-Spam-Status: No, score=-105.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pMkqILYG5uyD for ; Wed, 11 May 2011 05:16:39 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id C5896E0735 for ; Wed, 11 May 2011 05:16:38 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKTcp+Jqlv7A0crCMOC5fcBxA3ffXXgvLN@postini.com; Wed, 11 May 2011 05:16:38 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 919D81B8411 for ; Wed, 11 May 2011 05:16:36 -0700 (PDT) Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 7D95A19005D; Wed, 11 May 2011 05:16:36 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from vpna-148.vpn.nominum.com (64.89.227.148) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 11 May 2011 05:16:35 -0700 MIME-Version: 1.0 (Apple Message framework v1222) Content-Type: text/plain; charset="us-ascii" From: Ted Lemon In-Reply-To: Date: Wed, 11 May 2011 08:16:32 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <067E6CE33034954AAC05C9EC85E2577C04905E0E@XMB-RCD-111.cisco.com> <9105F293-1C25-4546-85B0-CF1E1A035CD9@nominum.com> To: Leaf yeh X-Mailer: Apple Mail (2.1222) Cc: "dhcwg@ietf.org" , Bernie Volz Subject: Re: [dhcwg] WG adoption of draft-asati-dhc-relay-agent-config-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: Wed, 11 May 2011 12:16:40 -0000 On May 10, 2011, at 11:50 PM, Leaf yeh wrote: > Ted - I will admit that in simply reading the draft, it does seem like = it's not actually doing anything, ... It occurs to me that one way to address this concern would be to write a = second draft that describes a suboption that would be a payload for this = mechanism. The two drafts, presented together, would make more sense = than this draft all on its own. From Ted.Lemon@nominum.com Wed May 11 05:19:41 2011 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 75247E06C7 for ; Wed, 11 May 2011 05:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.949 X-Spam-Level: X-Spam-Status: No, score=-105.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5RjyEB7joKp3 for ; Wed, 11 May 2011 05:19:41 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by ietfa.amsl.com (Postfix) with ESMTP id DB7C7E0670 for ; Wed, 11 May 2011 05:19:40 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKTcp+3MrHYnSizrhVuKTUGpDIz+LknR+5@postini.com; Wed, 11 May 2011 05:19:40 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 EBEDB1B87C3 for ; Wed, 11 May 2011 05:19:39 -0700 (PDT) Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id E417919005D; Wed, 11 May 2011 05:19:39 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from vpna-148.vpn.nominum.com (64.89.227.148) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 11 May 2011 05:19:39 -0700 MIME-Version: 1.0 (Apple Message framework v1222) Content-Type: text/plain; charset="us-ascii" From: Ted Lemon In-Reply-To: <969A86F7-D2B4-482D-8E2F-A845DB53D09F@employees.org> Date: Wed, 11 May 2011 08:19:34 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <048B15DF-1723-4938-993D-E7E3B31B6462@nominum.com> References: <94200415-3C9D-4C61-88AB-42A6D0E11649@nominum.com> <4DC864D1.8010101@gmail.com> <969A86F7-D2B4-482D-8E2F-A845DB53D09F@employees.org> To: Ole Troan X-Mailer: Apple Mail (2.1222) Cc: "dhcwg@ietf.orgWG WG" , Jouni Korhonen Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-pd-exclude-01 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, 11 May 2011 12:19:41 -0000 On May 11, 2011, at 3:16 AM, Ole Troan wrote: > good point, I wasn't aware of this. I also think including the ORO at = the correct option 'scope' is better. > any objections to that? I think this is a question implementors might want to think about. The = functioning of the ORO in situations like this is untrod ground, and it = might not do what you expect. From Ted.Lemon@nominum.com Wed May 11 05:23:12 2011 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 6E179E0746 for ; Wed, 11 May 2011 05:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.865 X-Spam-Level: X-Spam-Status: No, score=-105.865 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AdviamUO8LXh for ; Wed, 11 May 2011 05:23:12 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id A8835E06D1 for ; Wed, 11 May 2011 05:23:11 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKTcp/r1chuaXHbediGBzWGplpbiruwhTl@postini.com; Wed, 11 May 2011 05:23:11 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 EA3971B87C3 for ; Wed, 11 May 2011 05:23:10 -0700 (PDT) Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id DFDAB19005D; Wed, 11 May 2011 05:23:10 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from vpna-148.vpn.nominum.com (64.89.227.148) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 11 May 2011 05:23:10 -0700 MIME-Version: 1.0 (Apple Message framework v1222) Content-Type: multipart/alternative; boundary="Apple-Mail=_84F2194E-8942-4A63-8DE0-9154ECB10216" From: Ted Lemon In-Reply-To: Date: Wed, 11 May 2011 08:23:05 -0400 Message-ID: <99DF3B00-534F-4CA7-879B-8B64531C2513@nominum.com> References: To: Bernie Volz X-Mailer: Apple Mail (2.1222) Cc: dhcwg@ietf.org, "Kim Kinnear \(kkinnear\)" , "Ralph Droms \(rdroms\)" Subject: Re: [dhcwg] FYI - A note regarding DHCPv6 from Interop 2011 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, 11 May 2011 12:23:12 -0000 --Apple-Mail=_84F2194E-8942-4A63-8DE0-9154ECB10216 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="windows-1252" On May 11, 2011, at 2:50 AM, Bernie Volz (volz) wrote: > The one DHCPv6 issue that came up, which isn=92t new, is that there = were incidences of duplicate IPv6 address assigned from the DHCP Server = (Cisco Network Registrar) =96 this was obvious from the DHCPv6 DECLINE = messages which like DHCPv4 DHCPDECLINEs should generally NOT occur. This = was because one of the vendors that supplied PCs for A/V needs, attendee = use, and conference operations had cloned a Windows 7 machine and not = wiped out the Dhcpv6DUID registry key. (I suspect more than one vendor = might have been involved given the number of different DUIDs but it = could also have been different images for different system types.) Ouch. This is a problem we were concerned about; it's unfortunate to = see that it is prevalent in practice and not just something to worry = about. Doesn't Windows have a post-clone mechanism for wiping information that = needs to be configured on a per-machine basis? (I assume Windows = because you mentioned the registry). Thanks for bringing this up here! --Apple-Mail=_84F2194E-8942-4A63-8DE0-9154ECB10216 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="windows-1252"
The one DHCPv6 issue that came up, which isn=92t new, is = that there were incidences of duplicate IPv6 address assigned from the = DHCP Server (Cisco Network Registrar) =96 this was obvious from the = DHCPv6 DECLINE messages which like DHCPv4 DHCPDECLINEs should generally = NOT occur. This was because one of the vendors that supplied PCs for A/V = needs, attendee use, and conference operations had cloned a Windows 7 = machine and not wiped out the Dhcpv6DUID registry key. (I suspect more = than one vendor might have been involved given the number of different = DUIDs but it could also have been different images for different system = types.)

Ouch.   This is a = problem we were concerned about; it's unfortunate to see that it is = prevalent in practice and not just something to worry = about.

Doesn't Windows have a post-clone = mechanism for wiping information that needs to be configured on a = per-machine basis?   (I assume Windows because you mentioned the = registry).

Thanks for bringing this up = here!

= --Apple-Mail=_84F2194E-8942-4A63-8DE0-9154ECB10216-- From budmillwood@gmail.com Wed May 11 07:51:16 2011 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 F153FE07F2 for ; Wed, 11 May 2011 07:51:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TFVZ0z+ND3YP for ; Wed, 11 May 2011 07:51:16 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 29649E07EB for ; Wed, 11 May 2011 07:51:16 -0700 (PDT) Received: by vws12 with SMTP id 12so486441vws.31 for ; Wed, 11 May 2011 07:51:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=WFDsmSvgJftQj0KOrYG8y/uFokj4EVvYah/5d4i9b24=; b=nSTIYAA1odT4oW5xm0zWz4xifzJ0OjFsrSFwPToHdoIcFGFAfrelZQFJB6G+XJ2K0P rDiC0v5jVrTYuD7c7IzLZToQ4m0X796fsUV+f5viAAN29koe7zf9bQ2gOIlqTy5RPHVB KI1zYkoyXt4XGn6fyZAmcF/dZaXA1PaJFcS+8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=UegmEK+uEu1xm67QQyzwxK0r/yT8H3WErjWzu9dAmTzw7XDrqNIu3eqFn9fLCfJblR aRvRAaijsNTAwfazsuzc4FV/Y8GC4Ej3mfrpjCxxnZVPV0F3iKgMOffXhhsklBDJezje oavg5tGZdf/a9ucEH/QQ+o9uadGwKASHuGVIQ= MIME-Version: 1.0 Received: by 10.52.114.196 with SMTP id ji4mr2929221vdb.29.1305125473707; Wed, 11 May 2011 07:51:13 -0700 (PDT) Received: by 10.52.113.101 with HTTP; Wed, 11 May 2011 07:51:13 -0700 (PDT) In-Reply-To: <99DF3B00-534F-4CA7-879B-8B64531C2513@nominum.com> References: <99DF3B00-534F-4CA7-879B-8B64531C2513@nominum.com> Date: Wed, 11 May 2011 16:51:13 +0200 Message-ID: From: Bud Millwood To: Ted Lemon Content-Type: multipart/alternative; boundary=bcaec548a5033f65c104a30134b8 Cc: dhcwg@ietf.org, "Ralph Droms \(rdroms\)" , Bernie Volz , "Kim Kinnear \(kkinnear\)" Subject: Re: [dhcwg] FYI - A note regarding DHCPv6 from Interop 2011 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, 11 May 2011 14:51:17 -0000 --bcaec548a5033f65c104a30134b8 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable > > The one DHCPv6 issue that came up, which isn=92t new, is that there were > incidences of duplicate IPv6 address assigned from the DHCP Server (Cisco > Network Registrar) =96 this was obvious from the DHCPv6 DECLINE messages = which > like DHCPv4 DHCPDECLINEs should generally NOT occur. This was because one= of > the vendors that supplied PCs for A/V needs, attendee use, and conference > operations had cloned a Windows 7 machine and not wiped out the Dhcpv6DUI= D > registry key. (I suspect more than one vendor might have been involved gi= ven > the number of different DUIDs but it could also have been different image= s > for different system types.) > > > Ouch. This is a problem we were concerned about; it's unfortunate to se= e > that it is prevalent in practice and not just something to worry about. > > Doesn't Windows have a post-clone mechanism for wiping information that > needs to be configured on a per-machine basis? (I assume Windows becaus= e > you mentioned the registry). > > Thanks for bringing this up here! > We agree that this is not something to "fix" with DHCPv6, right? This is equivalent to cloning a machine that has a static address and leaving the same configuration. That said, relay agents that add hardware address to option 82 could make this easier to detect when relays are present. Just sayin'. :) - Bud --bcaec548a5033f65c104a30134b8 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
The one DHCPv6 issue that came up, which isn=92t new, is that there were in= cidences of duplicate IPv6 address assigned from the DHCP Server (Cisco Net= work Registrar) =96 this was obvious from the DHCPv6 DECLINE messages which= like DHCPv4 DHCPDECLINEs should generally NOT occur. This was because one = of the vendors that supplied PCs for A/V needs, attendee use, and conferenc= e operations had cloned a Windows 7 machine and not wiped out the Dhcpv6DUI= D registry key. (I suspect more than one vendor might have been involved gi= ven the number of different DUIDs but it could also have been different ima= ges for different system types.)

Ouch. =A0 This is a problem we wer= e concerned about; it's unfortunate to see that it is prevalent in prac= tice and not just something to worry about.

Doesn&= #39;t Windows have a post-clone mechanism for wiping information that needs= to be configured on a per-machine basis? =A0 (I assume Windows because you= mentioned the registry).

Thanks for bringing this up here!

We agree that this is not something to "fix&quo= t; with DHCPv6, right? This is equivalent to cloning a machine that has a s= tatic address and leaving the same configuration.

That said, relay agents that add hardware address to op= tion 82 could make this easier to detect when relays are present. Just sayi= n'. :)

- Bud

--bcaec548a5033f65c104a30134b8-- From mellon@fugue.com Wed May 11 08:06:29 2011 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 9B40CE0820 for ; Wed, 11 May 2011 08:06:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zvAEVzzAnule for ; Wed, 11 May 2011 08:06:29 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 382A9E081B for ; Wed, 11 May 2011 08:06:29 -0700 (PDT) Received: from [10.1.10.17] (173-162-214-218-NewEngland.hfc.comcastbusiness.net [173.162.214.218]) by toccata.fugue.com (Postfix) with ESMTPSA id 230C334E44E6 for ; Wed, 11 May 2011 11:07:00 -0400 (EDT) From: Ted Lemon Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Wed, 11 May 2011 11:06:24 -0400 Message-Id: <6280FDDC-D655-4FFD-8143-6C320A437F21@fugue.com> To: "dhcwg@ietf.orgWG WG" Mime-Version: 1.0 (Apple Message framework v1222) X-Mailer: Apple Mail (2.1222) Subject: [dhcwg] WGLC: draft-ietf-dhc-dhcpv4-bulk-leasequery-04.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, 11 May 2011 15:06:29 -0000 We agreed in Beijing to do a WGLC on this draft, but it never happened = (mea culpa). So, no time like the present. I'd like to see some discussion and review of the draft=97although it's = been presented in several meetings, there's been little discussion on = the list. However, based on what discussion and review has occurred in = context of in-person IETF meetings, I think that the draft is ready for = last call. So please review the draft and submit any comments and = suggestions you may have. Also, if you think the draft is ready for publication, please say so on = the mailing list. Likewise, if you think it is not ready, or shouldn't = be published, please say so. We will assess consensus on Thursday, May 26. Thanks! From Stephen.Jacob@nominum.com Wed May 11 11:42:03 2011 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 C89F4E0693 for ; Wed, 11 May 2011 11:42:03 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0MUnfuwNFFy7 for ; Wed, 11 May 2011 11:42:02 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 81793E066E for ; Wed, 11 May 2011 11:42:02 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKTcrYeZskB+C+tz9zWwIGW+hNCuNkYN45@postini.com; Wed, 11 May 2011 11:42:02 PDT Received: by shell-too.nominum.com (Postfix, from userid 11053) id 38D4F1B84A2; Wed, 11 May 2011 11:41:58 -0700 (PDT) Date: Wed, 11 May 2011 11:41:58 -0700 From: Stephen Jacob To: Tomasz Mrugalski Message-ID: <20110511184158.GB4138@shell-too.nominum.com> Mail-Followup-To: Tomasz Mrugalski , dhcwg@ietf.org References: <94200415-3C9D-4C61-88AB-42A6D0E11649@nominum.com> <4DC864D1.8010101@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DC864D1.8010101@gmail.com> User-Agent: Mutt/1.4.2.2i X-URI: http://www.nominum.com/ Organization: Nominum, Inc. Cc: dhcwg@ietf.org Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-pd-exclude-01 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, 11 May 2011 18:42:03 -0000 On Tue, May 10, 2011 at 12:04:01AM +0200, Tomasz Mrugalski wrote: > 3. Section 4.2 > "The OPTION_PD_EXCLUDE option MUST be located before the possible Status > Code option in the IAprefix-options field." Why forcing to use specific > order? DHCPv6 does not impose any restrictions regarding sequence, in > which options appear in a message or within other options. There's good > reason for that - implementations may keep the options in structures > other than simple lists or vector, like hash tables. Enforcing any > specific order would be troublesome in that case. I propose to remove > this sentence. I very much agree with Tomek. I would prefer that no draft impose option ordering constraints. It sounds like Ole agrees, which is great. :) > 5. PD_EXCLUDE option is going to be delivered in IAPREFIX that is > located in IA_PD (not in the message options field), but draft says that > requesting router should request PD_EXCLUDE in ORO placed in message > options field. Wouldn't it be more appropriate to put second instance of > ORO (with PD_EXCLUDE code) in IA_PD sent by requesting router? You may > consider reading draft-mrugalski-dhc-dhcpv6-suboptions and follow its > suggestions, if you that they are reasonable. That would seem to make more sense. It sounds like Ole agrees with this too, so I trust it'll be worked out. :) I have only one additional comment on this draft. It is not critical, and I know I'm commenting on this awfully late in the game... It is not wrong as-is, but I think it is a bit strange/confusing that OPTION_PD_EXCLUDE (in 4.2. Prefix Exclude Option) is defined in such a way that the "IPv6 subnet ID" is a suffix appended to the 'OPTION_IAPREFIX prefix-length', except maybe not ust a suffix because it has to be octet-aligned so it might include some of the bits of 'OPTION_IAPREFIX prefix-length'. I misunderstood the definition in section 4.2 until I read the example at the end. It also seems like a strange way to define option data. Does anything else use this way of declaring a sub-prefix? It would seem to me to have two pros: 1) It saves some number of bytes of option space. 2) It ensures that the OPTION_PD_EXCLUDE prefix is contained in the OPTION_IAPREFIX prefix[*]. [*] except if octet-alignment requires replication of the final few bits of the OPTION_IAPREFIX prefix, in which case those could be incorrectly included as different bit values, presumably, so it doesn't really even guarantee #2, does it? It would seem to have 2 cons: 1) It is hard to understand. 2) I think implementors may implement it incorrectly, causing interoperability issues. Given that pro #2 is a weak assurance and pro #1 only means saving a few bytes (how much does that really matter? I would say not at all), I think the cons significantly outweigh the pros. I would suggest that OPTION_PD_EXCLUDE ought to include the full prefix to exclude. A downside is that clients (Requesting Routers) will need to validate the value they receive to ensure that OPTION_PD_EXCLUDE is a subset of OPTION_IAPREFIX (but they already ought to do some validation due to the issue I raised in the subscript of pro #2, and that validation is harder to get right than a simple "is this prefix contained in this other prefix" comparison; something that one can probably do with existing library code). If a client fails to validate, that's its problem, and it will probably be ok anyway if we make it a MUST for the server that OPTION_PD_EXCLUDE be a subset of OPTION_IAPREFIX. For the server implementor, the up-side is not having to write custom code to handle this special kind of field type, and it means we don't create an option whose value is defined based on the value of another option (a situation which I also dislike). Regards, Stephen -- Stephen Jacob | Stephen.Jacob@nominum.com | +1 650 381 6051 Nominum, Inc. | http://www.nominum.com/ | +1 650 381 6000 From volz@cisco.com Wed May 11 12:33:40 2011 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 C0491E08A2 for ; Wed, 11 May 2011 12:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aRADRDKSCjPw for ; Wed, 11 May 2011 12:33:38 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id D8352E07F1 for ; Wed, 11 May 2011 12:33:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=12968; q=dns/txt; s=iport; t=1305142418; x=1306352018; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=7SF3hrw0+pE5XlMa185fr4L+B7B0U9oJ9ig+L1rXZm0=; b=UHwCPc5jvFobLNjrSru8xW4SV+Jm46YeYeNlzj2LPNJIwplLy04m1N62 /sKVJVxcP9Sv1cMpA58+YIy2/5IIsN3CSsi6xCYYL9r4luuGvxi7zvTQB 8FggIuT15E0SSKg9Vtq4pPIhigxrTZ9pOWYHTdIk+Hbw1SJW8kJJgzww6 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQBAM/jyk2tJXG8/2dsb2JhbACCZZRsjjJ3qgyeLoYQBIZDjV2EEYY+ X-IronPort-AV: E=Sophos;i="4.64,354,1301875200"; d="scan'208,217";a="313527130" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by sj-iport-3.cisco.com with ESMTP; 11 May 2011 19:33:37 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p4BJXbZX023163; Wed, 11 May 2011 19:33:37 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); Wed, 11 May 2011 14:33:37 -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_01CC1012.5307B380" Date: Wed, 11 May 2011 14:33:08 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] FYI - A note regarding DHCPv6 from Interop 2011 Thread-Index: AcwP6uHTSsIZWdIxSBa/PIITpQDvagAJxt6Q References: <99DF3B00-534F-4CA7-879B-8B64531C2513@nominum.com> From: "Bernie Volz (volz)" To: "Bud Millwood" , "Ted Lemon" X-OriginalArrivalTime: 11 May 2011 19:33:37.0402 (UTC) FILETIME=[52F315A0:01CC1012] Cc: dhcwg@ietf.org, "Ralph Droms \(rdroms\)" , "Kim Kinnear \(kkinnear\)" Subject: Re: [dhcwg] FYI - A note regarding DHCPv6 from Interop 2011 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, 11 May 2011 19:33:40 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC1012.5307B380 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable >We agree that this is not something to "fix" with DHCPv6, right? This >is equivalent to cloning a machine that has a static address and leaving >the same configuration. =20 Correct. Just something that is important for the "world" to know about ... when cloning a system, make sure to 'reset' the DHCP DUID. =20 People seem to understand that one must change the hostname, etc, but they may not be as aware of this issue. =20 - Bernie =20 From: Bud Millwood [mailto:budmillwood@gmail.com]=20 Sent: Wednesday, May 11, 2011 10:51 AM To: Ted Lemon Cc: Bernie Volz (volz); dhcwg@ietf.org; Kim Kinnear (kkinnear); Ralph Droms (rdroms); Brzozowski, John Subject: Re: [dhcwg] FYI - A note regarding DHCPv6 from Interop 2011 =20 The one DHCPv6 issue that came up, which isn't new, is that there were incidences of duplicate IPv6 address assigned from the DHCP Server (Cisco Network Registrar) - this was obvious from the DHCPv6 DECLINE messages which like DHCPv4 DHCPDECLINEs should generally NOT occur. This was because one of the vendors that supplied PCs for A/V needs, attendee use, and conference operations had cloned a Windows 7 machine and not wiped out the Dhcpv6DUID registry key. (I suspect more than one vendor might have been involved given the number of different DUIDs but it could also have been different images for different system types.) =20 Ouch. This is a problem we were concerned about; it's unfortunate to see that it is prevalent in practice and not just something to worry about. =20 Doesn't Windows have a post-clone mechanism for wiping information that needs to be configured on a per-machine basis? (I assume Windows because you mentioned the registry). =20 Thanks for bringing this up here! =20 We agree that this is not something to "fix" with DHCPv6, right? This is equivalent to cloning a machine that has a static address and leaving the same configuration. =20 That said, relay agents that add hardware address to option 82 could make this easier to detect when relays are present. Just sayin'. :) =20 - Bud =20 ------_=_NextPart_001_01CC1012.5307B380 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

>We = agree that this is not something to "fix" with DHCPv6, right? = This

>is equivalent to cloning a = machine that has a static address and leaving

>the same configuration.

 

Correct. Just something that is important for the “world” = to know about … when cloning a system, make sure to = ‘reset’ the DHCP DUID.

 

People seem to understand that one must change the hostname, etc, but = they may not be as aware of this issue.

 

-          = Bernie

 

From:= = Bud Millwood [mailto:budmillwood@gmail.com]
Sent: Wednesday, = May 11, 2011 10:51 AM
To: Ted Lemon
Cc: Bernie Volz = (volz); dhcwg@ietf.org; Kim Kinnear (kkinnear); Ralph Droms (rdroms); = Brzozowski, John
Subject: Re: [dhcwg] FYI - A note regarding = DHCPv6 from Interop 2011

 

The one = DHCPv6 issue that came up, which isn’t new, is that there were = incidences of duplicate IPv6 address assigned from the DHCP Server = (Cisco Network Registrar) – this was obvious from the DHCPv6 = DECLINE messages which like DHCPv4 DHCPDECLINEs should generally NOT = occur. This was because one of the vendors that supplied PCs for A/V = needs, attendee use, and conference operations had cloned a Windows 7 = machine and not wiped out the Dhcpv6DUID registry key. (I suspect more = than one vendor might have been involved given the number of different = DUIDs but it could also have been different images for different system = types.)

 

Ouch.   This is a problem we were concerned = about; it's unfortunate to see that it is prevalent in practice and not = just something to worry about.

 

Doesn't Windows have a post-clone mechanism for wiping = information that needs to be configured on a per-machine basis?   = (I assume Windows because you mentioned the = registry).

 

Thanks for bringing this up = here!

 

We agree that this is not something to "fix" = with DHCPv6, right? This is equivalent to cloning a machine that has a = static address and leaving the same = configuration.

 

That said, relay agents that add hardware address to = option 82 could make this easier to detect when relays are present. Just = sayin'. :)

 

- = Bud

 

------_=_NextPart_001_01CC1012.5307B380-- From volz@cisco.com Wed May 11 12:56:27 2011 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 A4B3BE08AF for ; Wed, 11 May 2011 12:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z+LFSOCBSlb7 for ; Wed, 11 May 2011 12:56:26 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2BA44E07BA for ; Wed, 11 May 2011 12:56:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=3660; q=dns/txt; s=iport; t=1305143786; x=1306353386; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=IJ+QhacPCscjUFI3ZXh3hgoxDK988EdXHXWBfCAqMSw=; b=LlnqozVptnupRsoJegEGk1lMjaZ3eAccRWkjfgOVbuoQhqtCRt+GPZt1 x7KtOUnTSQz0gOxVcTbLizgtGey8E/sHmx9AS+V+H8eAyX1dfBGzYH25M DSceunvi8Q2sMzg4Wajtn+m/wcdZ7yN1G1g4sIkHR4I9bDgLiRMZSW+rh 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQBAJzoyk2tJXG+/2dsb2JhbACXUY4yd6l+ni6DJoJqBIZDjV2KTw X-IronPort-AV: E=Sophos;i="4.64,354,1301875200"; d="scan'208";a="313541853" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by sj-iport-3.cisco.com with ESMTP; 11 May 2011 19:56:25 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p4BJuPBi020050; Wed, 11 May 2011 19:56:25 GMT Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 May 2011 14:56: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: Wed, 11 May 2011 14:56:23 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] FYI - A note regarding DHCPv6 from Interop 2011 Thread-Index: AcwPp7iTxLJMabhYQrKvdxna/otGHAAKonoAABCssxA= References: From: "Bernie Volz (volz)" To: "Brzozowski, John" , "Ralph Droms (rdroms)" , "dhc WG" X-OriginalArrivalTime: 11 May 2011 19:56:24.0980 (UTC) FILETIME=[8216ED40:01CC1015] Cc: "Kim Kinnear \(kkinnear\)" Subject: Re: [dhcwg] FYI - A note regarding DHCPv6 from Interop 2011 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, 11 May 2011 19:56:27 -0000 Interop is big trade show and provides network access to attendees, = exhibitors, and the show infrastructure (registration, etc). See = http://www.interop.com/lasvegas/. These were Windows 7 PCs. This is just an issue in the cloning process - just as they changed the = host name after cloning, they have to assure they wipe out the DHCP DUID = so that a new one will be generated. I would assume that Microsoft's = "SYSPREP" does this (I really don't know much about SYSPREP but as I = understand it, it is supposed to be used in the cloning process to fix = up the registry, etc for the new system after it is cloned; indications = are that this might not have been run). We found no issues with normal clients (i.e., those from attendees or = exhibitors). - Bernie -----Original Message----- From: Brzozowski, John [mailto:John_Brzozowski@Cable.Comcast.com]=20 Sent: Wednesday, May 11, 2011 7:55 AM To: Bernie Volz (volz); Ralph Droms (rdroms); dhc WG Cc: Kim Kinnear (kkinnear) Subject: Re: [dhcwg] FYI - A note regarding DHCPv6 from Interop 2011 Bernie, Are there any more details available, specifically what OSes or devices supported DHCPv6 and IPv6? Apologies for uninformed questions, I am not familiar with how Interop = is run. Will they issue any sort of report or paper outlining the activities/testing? Thanks, John =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D John Jason Brzozowski Comcast Cable e) mailto:john_brzozowski@cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On 5/11/11 2:50 AM, "Bernie Volz (volz)" wrote: >I have been at Interop 2011 working as part of the InteropNet team as >Cisco is a sponsor/provider of the network. >=20 >The one DHCPv6 issue that came up, which isn=B9t new, is that there = were >incidences of duplicate IPv6 address assigned from the DHCP Server = (Cisco >Network Registrar) =AD this was obvious from the DHCPv6 DECLINE = messages >which like DHCPv4 DHCPDECLINEs should generally NOT occur. This was >because one of the vendors that supplied PCs for A/V needs, attendee = use, >and conference operations had cloned a Windows 7 machine and not wiped >out the Dhcpv6DUID registry key. (I suspect more than one vendor might >have been involved given the number of different DUIDs but it could = also >have been different images for different system types.) >=20 >I suspect that this will be a reoccurring issue and I figured it was >worth highlighting, at least to the DHC WG mailing list. The more = people >that know about this requirement, the better =AD both in reducing its >occurrence in the first place, and understanding what it is and how to >resolve it should It happen. >=20 >It was pretty easy to resolve on a machine-by-machine basis (in some >cases, IPv6 was disabled; in others the registry key was deleted and >machine rebooted). >=20 >Incidentally, between 33% and 40% of the DHCPv4 devices (visitors, >exhibitors, conference operations) likely support DHCPv6 which was, to = me >at least, a surprisingly high percentage (this figure is based on the >percentage of active leases =AD DHCPv6 count / DHCPv4 count). But this = is >good news for DHCPv6 and IPv6 in general. >=20 >- Bernie > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www.ietf.org/mailman/listinfo/dhcwg From jouni.nospam@gmail.com Wed May 11 14:48:35 2011 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 39274E08A6 for ; Wed, 11 May 2011 14:48:35 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFXCr9vZ8v4a for ; Wed, 11 May 2011 14:48:34 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1FFF5E089C for ; Wed, 11 May 2011 14:48:33 -0700 (PDT) Received: by eye13 with SMTP id 13so336753eye.31 for ; Wed, 11 May 2011 14:48:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=SL0h1KKQ3pPvvm5gA8BaSBRROnkVnb21fBtY45zwQWA=; b=jIN8GeS8HA5cB//82mWDdS7B0WKob1ZBKaMrnNDeXqKic3GTxkf5FHtrFVtLWnzBG3 R7TnuLLyUNK9BE70u3HN2AT/1bSYipqbWgYKAL+VWEHHjaxEMZ3j5iYBOY8Wbt6Ob/nw PrXSHjkCx4S71btSG+bCDpq3UXfEuHzKqSudw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=VYyakoDaX28pq0uvvtx0NMDMRv0cInBMwLaNA7yZzUApRLfNWFQ3XaplWaLLlMAuVs HWAL493sXY9EpyY3crwfmlPLaFKr8x30UDiC+rscO1rMnc0xYlFY1rm2FIO+R3Eo2a04 UT/6REmzjqXslVFYFTCcjiOYail7Q6kin+rnU= Received: by 10.14.44.135 with SMTP id n7mr4421178eeb.130.1305150513041; Wed, 11 May 2011 14:48:33 -0700 (PDT) Received: from a88-114-65-87.elisa-laajakaista.fi (a88-114-65-87.elisa-laajakaista.fi [88.114.65.87]) by mx.google.com with ESMTPS id u6sm235786eeu.16.2011.05.11.14.48.31 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 11 May 2011 14:48:31 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <20110511184158.GB4138@shell-too.nominum.com> Date: Thu, 12 May 2011 00:48:29 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <68614430-1044-45EE-9B64-354284B13D87@gmail.com> References: <94200415-3C9D-4C61-88AB-42A6D0E11649@nominum.com> <4DC864D1.8010101@gmail.com> <20110511184158.GB4138@shell-too.nominum.com> To: Stephen Jacob X-Mailer: Apple Mail (2.1082) Cc: dhcwg@ietf.org Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-pd-exclude-01 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, 11 May 2011 21:48:35 -0000 Hi, On May 11, 2011, at 9:41 PM, Stephen Jacob wrote: [snip] >=20 > I have only one additional comment on this draft. It is not critical, > and I know I'm commenting on this awfully late in the game... >=20 > It is not wrong as-is, but I think it is a bit strange/confusing that > OPTION_PD_EXCLUDE (in 4.2. Prefix Exclude Option) is defined in such > a way that the "IPv6 subnet ID" is a suffix appended to the > 'OPTION_IAPREFIX prefix-length', except maybe not ust a suffix because > it has to be octet-aligned so it might include some of the bits of > 'OPTION_IAPREFIX prefix-length'. >=20 > I misunderstood the definition in section 4.2 until I read the > example at the end. >=20 > It also seems like a strange way to define option data. Does anything > else use this way of declaring a sub-prefix? >=20 > It would seem to me to have two pros: >=20 > 1) It saves some number of bytes of option space. > 2) It ensures that the OPTION_PD_EXCLUDE prefix is contained > in the OPTION_IAPREFIX prefix[*]. >=20 > [*] except if octet-alignment requires replication of > the final few bits of the OPTION_IAPREFIX prefix, > in which case those could be incorrectly included > as different bit values, presumably, so it doesn't > really even guarantee #2, does it? I don't get the issue you are seeing here. Could you give an example of = an incorrect case? >=20 > It would seem to have 2 cons: >=20 > 1) It is hard to understand. > 2) I think implementors may implement it incorrectly, causing > interoperability issues. >=20 > Given that pro #2 is a weak assurance and pro #1 only means saving a > few bytes (how much does that really matter? I would say not at all), > I think the cons significantly outweigh the pros. >=20 > I would suggest that OPTION_PD_EXCLUDE ought to include the full > prefix to exclude. I.e. back to formatting we still had in = draft-korhonen-dhc-pd-exclude-01.. until it got changed because of the = concerns raised that are here listed as pros 1) and 2). I am OK going = back to old encoding. - Jouni >=20 > A downside is that clients (Requesting Routers) will need to validate > the value they receive to ensure that OPTION_PD_EXCLUDE is a subset > of OPTION_IAPREFIX (but they already ought to do some validation due > to the issue I raised in the subscript of pro #2, and that validation > is harder to get right than a simple "is this prefix contained in > this other prefix" comparison; something that one can probably do > with existing library code). >=20 > If a client fails to validate, that's its problem, and it will > probably be ok anyway if we make it a MUST for the server that > OPTION_PD_EXCLUDE be a subset of OPTION_IAPREFIX. >=20 > For the server implementor, the up-side is not having to write custom > code to handle this special kind of field type, and it means we don't > create an option whose value is defined based on the value of another > option (a situation which I also dislike). >=20 > Regards, > Stephen > --=20 > Stephen Jacob | Stephen.Jacob@nominum.com | +1 650 381 6051 > Nominum, Inc. | http://www.nominum.com/ | +1 650 381 6000 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From Ted.Lemon@nominum.com Wed May 11 15:53:21 2011 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 AAC71E0696 for ; Wed, 11 May 2011 15:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.198 X-Spam-Level: X-Spam-Status: No, score=-106.198 tagged_above=-999 required=5 tests=[AWL=0.399, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gSYgp4G+1FDL for ; Wed, 11 May 2011 15:53:21 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id E8F8DE06DA for ; Wed, 11 May 2011 15:53:20 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKTcsTYPywPhemhR/yeuDQOoXrWsWCJtQL@postini.com; Wed, 11 May 2011 15:53:21 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 D74461B876D for ; Wed, 11 May 2011 15:53:17 -0700 (PDT) Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id C681E190052; Wed, 11 May 2011 15:53:17 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from vpna-148.vpn.nominum.com (64.89.227.148) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 11 May 2011 15:53:17 -0700 MIME-Version: 1.0 (Apple Message framework v1222) Content-Type: multipart/alternative; boundary="Apple-Mail=_91E2EADF-43AB-4208-9EDF-1C64E004FDDA" From: Ted Lemon In-Reply-To: Date: Wed, 11 May 2011 18:53:12 -0400 Message-ID: References: <99DF3B00-534F-4CA7-879B-8B64531C2513@nominum.com> To: Bud Millwood X-Mailer: Apple Mail (2.1222) Cc: dhcwg@ietf.org, "Ralph Droms \(rdroms\)" , Bernie Volz , "Kim Kinnear \(kkinnear\)" Subject: Re: [dhcwg] FYI - A note regarding DHCPv6 from Interop 2011 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, 11 May 2011 22:53:21 -0000 --Apple-Mail=_91E2EADF-43AB-4208-9EDF-1C64E004FDDA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" On May 11, 2011, at 10:51 AM, Bud Millwood wrote: > That said, relay agents that add hardware address to option 82 could = make this easier to detect when relays are present. Just sayin'. :) Huh? --Apple-Mail=_91E2EADF-43AB-4208-9EDF-1C64E004FDDA Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="us-ascii"
On May 11, 2011, at 10:51 AM, Bud Millwood wrote:
That said, relay agents that add hardware address to option 82 could make this easier to detect when relays are present. Just sayin'. :)

Huh?

--Apple-Mail=_91E2EADF-43AB-4208-9EDF-1C64E004FDDA-- From volz@cisco.com Wed May 11 16:15:22 2011 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 54929E07D4 for ; Wed, 11 May 2011 16:15:22 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8qkXE2WQs0jM for ; Wed, 11 May 2011 16:15:17 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 281B2E06DA for ; Wed, 11 May 2011 16:15:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=10337; q=dns/txt; s=iport; t=1305155717; x=1306365317; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=tjObbIlUdd1GtaLYlKy6RlNooD50uCHNDEyTm7cGUJs=; b=SwqrDTzNx/m6a5h+bK4X2DP3vZi/SjkXvOsel93uSB7prKMBlLARLWem JdbtBOBNaHyVkfgKKi+KsNTdioLp021DXBnizgkPRBlMLK9jiY3mhWT6m lrgL+hgoQ4IPxF2AUJuWFWst7a3TyFRhh9tZvcXkAmcc2cyzjXNoCBUNu s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYBAAsYy02tJXG+/2dsb2JhbACCZJRZjjN3qmGeOIYRBIZEjV+KUg X-IronPort-AV: E=Sophos;i="4.64,354,1301875200"; d="scan'208,217";a="355211342" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by sj-iport-2.cisco.com with ESMTP; 11 May 2011 23:15:16 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p4BNFGNG006066; Wed, 11 May 2011 23:15:16 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); Wed, 11 May 2011 18:15:15 -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_01CC1031.497C4468" Date: Wed, 11 May 2011 18:15:14 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] FYI - A note regarding DHCPv6 from Interop 2011 Thread-Index: AcwQLjqPsYK+XUV2R5OJNIBNBJC/NwAAr18A References: <99DF3B00-534F-4CA7-879B-8B64531C2513@nominum.com> From: "Bernie Volz (volz)" To: "Bud Millwood" X-OriginalArrivalTime: 11 May 2011 23:15:15.0781 (UTC) FILETIME=[4966AF50:01CC1031] Cc: dhcwg@ietf.org, "Ralph Droms \(rdroms\)" , "Kim Kinnear \(kkinnear\)" Subject: Re: [dhcwg] FYI - A note regarding DHCPv6 from Interop 2011 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, 11 May 2011 23:15:22 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC1031.497C4468 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Bud ... Wrong protocol ... you are thinking DHCPv4 not DHCPv6 ... Relay-Forward is used in DHCPv6. =20 Yeah, I was thinking the peer-address might have been useful but at least in some cases it was not. This seemed very odd to me (it was also odd that the DUID the Windows system created was not based on the mac address of the interface). But I just didn't have the time to diagnose it further. =20 I might have some additional data to help but it will be a while before I can fully analyze it. =20 - Bernie =20 From: Ted Lemon [mailto:Ted.Lemon@nominum.com]=20 Sent: Wednesday, May 11, 2011 6:53 PM To: Bud Millwood Cc: Bernie Volz (volz); dhcwg@ietf.org; Kim Kinnear (kkinnear); Ralph Droms (rdroms); Brzozowski, John Subject: Re: [dhcwg] FYI - A note regarding DHCPv6 from Interop 2011 =20 On May 11, 2011, at 10:51 AM, Bud Millwood wrote: That said, relay agents that add hardware address to option 82 could make this easier to detect when relays are present. Just sayin'. :) =20 Huh? =20 ------_=_NextPart_001_01CC1031.497C4468 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Bud … Wrong protocol … you are thinking DHCPv4 not DHCPv6 = … Relay-Forward is used in DHCPv6.

 

Yeah, I was thinking the peer-address might have been useful but at = least in some cases it was not. This seemed very odd to me (it was also = odd that the DUID the Windows system created was not based on the mac = address of the interface). But I just didn’t have the time to = diagnose it further.

 

I might have some additional data to help but it will be a while = before I can fully analyze it.

 

-          = Bernie

 

From:= = Ted Lemon [mailto:Ted.Lemon@nominum.com]
Sent: Wednesday, May = 11, 2011 6:53 PM
To: Bud Millwood
Cc: Bernie Volz = (volz); dhcwg@ietf.org; Kim Kinnear (kkinnear); Ralph Droms (rdroms); = Brzozowski, John
Subject: Re: [dhcwg] FYI - A note regarding = DHCPv6 from Interop 2011

 

On = May 11, 2011, at 10:51 AM, Bud Millwood = wrote:

That said, relay = agents that add hardware address to option 82 could make this easier to = detect when relays are present. Just sayin'. = :)

 

Huh?

 

------_=_NextPart_001_01CC1031.497C4468-- From akostur@incognito.com Wed May 11 16:46:18 2011 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 8549AE08E5 for ; Wed, 11 May 2011 16:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uvHOLMa-axoO for ; Wed, 11 May 2011 16:46:17 -0700 (PDT) Received: from na3sys010aog107.obsmtp.com (na3sys010aog107.obsmtp.com [74.125.245.82]) by ietfa.amsl.com (Postfix) with SMTP id 34F1BE065A for ; Wed, 11 May 2011 16:46:16 -0700 (PDT) Received: from mail-vx0-f180.google.com ([209.85.220.180]) (using TLSv1) by na3sys010aob107.postini.com ([74.125.244.12]) with SMTP ID DSNKTcsfx5u+VHyIol+aQnaJzwTWU9cF/20t@postini.com; Wed, 11 May 2011 16:46:17 PDT Received: by vxk12 with SMTP id 12so1329266vxk.39 for ; Wed, 11 May 2011 16:46:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.76.38 with SMTP id h6mr2109646vdw.156.1305157574834; Wed, 11 May 2011 16:46:14 -0700 (PDT) Received: by 10.52.188.232 with HTTP; Wed, 11 May 2011 16:46:14 -0700 (PDT) In-Reply-To: References: <99DF3B00-534F-4CA7-879B-8B64531C2513@nominum.com> Date: Wed, 11 May 2011 16:46:14 -0700 Message-ID: From: Andre Kostur To: "Bernie Volz (volz)" Content-Type: multipart/alternative; boundary=20cf3071cfd09fb8b304a308add8 Cc: dhcwg@ietf.org, "Kim Kinnear \(kkinnear\)" , "Ralph Droms \(rdroms\)" Subject: Re: [dhcwg] FYI - A note regarding DHCPv6 from Interop 2011 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, 11 May 2011 23:46:18 -0000 --20cf3071cfd09fb8b304a308add8 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable At least on my Windows machine, the DUID is based on the MAC address. DUID-LLT. On Wed, May 11, 2011 at 16:15, Bernie Volz (volz) wrote: > Bud =85 Wrong protocol =85 you are thinking DHCPv4 not DHCPv6 =85 Relay-F= orward > is used in DHCPv6. > > > > Yeah, I was thinking the peer-address might have been useful but at least > in some cases it was not. This seemed very odd to me (it was also odd tha= t > the DUID the Windows system created was not based on the mac address of t= he > interface). But I just didn=92t have the time to diagnose it further. > > > > I might have some additional data to help but it will be a while before I > can fully analyze it. > > > > - Bernie > > > > *From:* Ted Lemon [mailto:Ted.Lemon@nominum.com] > *Sent:* Wednesday, May 11, 2011 6:53 PM > *To:* Bud Millwood > > *Cc:* Bernie Volz (volz); dhcwg@ietf.org; Kim Kinnear (kkinnear); Ralph > Droms (rdroms); Brzozowski, John > *Subject:* Re: [dhcwg] FYI - A note regarding DHCPv6 from Interop 2011 > > > > On May 11, 2011, at 10:51 AM, Bud Millwood wrote: > > That said, relay agents that add hardware address to option 82 could make > this easier to detect when relays are present. Just sayin'. :) > > > > Huh? > > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > > --=20 Andre Kostur Senior Software Design Engineer P: 604-678-2864 SIP: 864@incognito.com --20cf3071cfd09fb8b304a308add8 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
At least on my Windows machine, the DUID is based on the M= AC address. =A0DUID-LLT.


= On Wed, May 11, 2011 at 16:15, Bernie Volz (volz) <volz@cisco.com> wrote:

Bud =85 Wrong protocol =85 you are t= hinking DHCPv4 not DHCPv6 =85 Relay-Forward is used in DHCPv6.

=A0

Yeah, I was thinking the peer-address might have been useful but at lea= st in some cases it was not. This seemed very odd to me (it was also odd th= at the DUID the Windows system created was not based on the mac address of = the interface). But I just didn=92t have the time to diagnose it further.

=A0

I might have some additional data to help but it will be a while before= I can fully analyze it.

=A0

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 <= /span>Bernie

=A0

From: Ted Lemon [mailto:= Ted.Lemon@nominu= m.com]
Sent: Wednesday, May 11, 2011 6:53 PM
To: Bud Millwood


Cc: Bernie Volz (volz); dhcwg@ietf.org; Kim Kinnear (kkinn= ear); Ralph Droms (rdroms); Brzozowski, John
Subject: Re: [dhcwg] FYI - A note regarding = DHCPv6 from Interop 2011

=A0=

On May 11, 2011, at 10:51 AM, Bud Mill= wood wrote:

That said, relay agents that add= hardware address to option 82 could make this easier to detect when relays= are present. Just sayin'. :)

=A0

Huh?

=A0


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dhcwg




--
Andre Kostur
Se= nior Software Design Engineer
P: 604-678-2864 =A0SIP: 864@incognito.com


--20cf3071cfd09fb8b304a308add8-- From volz@cisco.com Wed May 11 16:57:41 2011 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 11F75E0899 for ; Wed, 11 May 2011 16:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.873 X-Spam-Level: X-Spam-Status: No, score=-9.873 tagged_above=-999 required=5 tests=[AWL=-0.275, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yPB5beV7pPFv for ; Wed, 11 May 2011 16:57:39 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 60EE7E0663 for ; Wed, 11 May 2011 16:57:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=17843; q=dns/txt; s=iport; t=1305158259; x=1306367859; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=ikRQE+W2P2MawBwsPWeso2eczTDzsHmYHShp37lu8ws=; b=lftLgzP90rn//1Nt6HZGjaTqeck+7U6G5eK0uU5dVupmvwxa/M1bkFGY 2u4vlixgFDBiQafoir+FDfxtDYJDjjIZyUagqFwhfGb7aA8IkmHnHpdh9 poIo0pC1QKX1cbevvnLEyAcuZJJ9TVdzL84WTejGzj69kANs9tsZfnLWU 0=; X-Files: ~WRD000.jpg : 823 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkQCAOshy02tJXG8/2dsb2JhbAAvgWFUlFmOM3erM549gyeCagSGRI1filI X-IronPort-AV: E=Sophos;i="4.64,355,1301875200"; d="jpg'145?scan'145,208,217,145";a="313698880" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by sj-iport-3.cisco.com with ESMTP; 11 May 2011 23:57:38 +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.3/8.14.3) with ESMTP id p4BNvcIq017879; Wed, 11 May 2011 23:57:38 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); Wed, 11 May 2011 18:57:37 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CC1037.34A5440C" Date: Wed, 11 May 2011 18:57:21 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] FYI - A note regarding DHCPv6 from Interop 2011 Thread-Index: AcwQNZ+L1DdXKk5+TxmebKLr6T30ngAACYaw References: <99DF3B00-534F-4CA7-879B-8B64531C2513@nominum.com> From: "Bernie Volz (volz)" To: "Andre Kostur" X-OriginalArrivalTime: 11 May 2011 23:57:37.0687 (UTC) FILETIME=[347EC270:01CC1037] Cc: dhcwg@ietf.org, "Kim Kinnear \(kkinnear\)" , "Ralph Droms \(rdroms\)" Subject: Re: [dhcwg] FYI - A note regarding DHCPv6 from Interop 2011 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, 11 May 2011 23:57:41 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC1037.34A5440C Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CC1037.34A5440C" ------_=_NextPart_002_01CC1037.34A5440C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, exactly. That was why it was rather odd that deleting the registry key and rebooting didn't generate one based on the MAC (it was a DUID-LLT but not based on the MAC of the NIC card). =20 The NIC OUI was 00-21-86. The "bad" DUID had 01-1e-37. New DUID used 01-1a-6b in the case where I recorded the information. =20 All 3 of these OUI's belong to "Universal Global Scientific Industrial Co., Ltd". =20 - Bernie =20 From: Andre Kostur [mailto:akostur@incognito.com]=20 Sent: Wednesday, May 11, 2011 7:46 PM To: Bernie Volz (volz) Cc: Bud Millwood; dhcwg@ietf.org; Ralph Droms (rdroms); Kim Kinnear (kkinnear) Subject: Re: [dhcwg] FYI - A note regarding DHCPv6 from Interop 2011 =20 At least on my Windows machine, the DUID is based on the MAC address. DUID-LLT. =20 =20 On Wed, May 11, 2011 at 16:15, Bernie Volz (volz) wrote: Bud ... Wrong protocol ... you are thinking DHCPv4 not DHCPv6 ... Relay-Forward is used in DHCPv6. =20 Yeah, I was thinking the peer-address might have been useful but at least in some cases it was not. This seemed very odd to me (it was also odd that the DUID the Windows system created was not based on the mac address of the interface). But I just didn't have the time to diagnose it further. =20 I might have some additional data to help but it will be a while before I can fully analyze it. =20 - Bernie =20 From: Ted Lemon [mailto:Ted.Lemon@nominum.com]=20 Sent: Wednesday, May 11, 2011 6:53 PM To: Bud Millwood Cc: Bernie Volz (volz); dhcwg@ietf.org; Kim Kinnear (kkinnear); Ralph Droms (rdroms); Brzozowski, John Subject: Re: [dhcwg] FYI - A note regarding DHCPv6 from Interop 2011 =20 On May 11, 2011, at 10:51 AM, Bud Millwood wrote: That said, relay agents that add hardware address to option 82 could make this easier to detect when relays are present. Just sayin'. :) =20 Huh? =20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg --=20 Andre Kostur Senior Software Design Engineer P: 604-678-2864 SIP: 864@incognito.com =20 =20 ------_=_NextPart_002_01CC1037.34A5440C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes, exactly. That was why it was rather odd that deleting the = registry key and rebooting didn’t generate one based on the MAC = (it was a DUID-LLT but not based on the MAC of the NIC = card).

 

The NIC OUI was 00-21-86. The “bad” DUID had 01-1e-37. = New DUID used 01-1a-6b in the case where I recorded the = information.

 

All 3 of these OUI’s belong to “Universal Global = Scientific Industrial Co., Ltd”.

 

-          = Bernie

 

From:= = Andre Kostur [mailto:akostur@incognito.com]
Sent: Wednesday, = May 11, 2011 7:46 PM
To: Bernie Volz (volz)
Cc: Bud = Millwood; dhcwg@ietf.org; Ralph Droms (rdroms); Kim Kinnear = (kkinnear)
Subject: Re: [dhcwg] FYI - A note regarding DHCPv6 = from Interop 2011

 

At = least on my Windows machine, the DUID is based on the MAC address. =  DUID-LLT.

 

 

On Wed, = May 11, 2011 at 16:15, Bernie Volz (volz) <volz@cisco.com> = wrote:

Bud … Wrong protocol = … you are thinking DHCPv4 not DHCPv6 … Relay-Forward is used = in DHCPv6.

 

Yeah, I was thinking the = peer-address might have been useful but at least in some cases it was = not. This seemed very odd to me (it was also odd that the DUID the = Windows system created was not based on the mac address of the = interface). But I just didn’t have the time to diagnose it = further.

 

I might have some additional = data to help but it will be a while before I can fully analyze = it.

 

<= span style=3D'font-size:11.0pt;color:#1F497D'>-     &nb= sp;    Bernie

 

From: Ted Lemon [mailto:Ted.Lemon@nominum.com]
Sent: Wednesday, = May 11, 2011 6:53 PM
To: Bud = Millwood


Cc: = Bernie Volz (volz); dhcwg@ietf.org; Kim Kinnear (kkinnear); Ralph = Droms (rdroms); Brzozowski, John

Subject: Re: [dhcwg] FYI - A note regarding = DHCPv6 from Interop 2011

 <= /o:p>

On May 11, = 2011, at 10:51 AM, Bud Millwood = wrote:

That said, relay = agents that add hardware address to option 82 could make this easier to = detect when relays are present. Just sayin'. = :)

 <= /o:p>

Huh?

 <= /o:p>


______________________________________= _________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg




--
Andre = Kostur

Senior Software Design = Engineer

P: 604-678-2864 =  SIP: 864@incognito.com

3D"Image

 

------_=_NextPart_002_01CC1037.34A5440C-- ------_=_NextPart_001_01CC1037.34A5440C Content-Type: image/jpeg; name="~WRD000.jpg" Content-Transfer-Encoding: base64 Content-ID: <~WRD000.jpg> Content-Description: ~WRD000.jpg Content-Location: %7EWRD000.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCABkAGQDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD3+iii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigD//2Q== ------_=_NextPart_001_01CC1037.34A5440C-- From fs@WPI.EDU Wed May 11 16:59:56 2011 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 46496E0691 for ; Wed, 11 May 2011 16:59:56 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yiC6rnh0Bx2X for ; Wed, 11 May 2011 16:59:55 -0700 (PDT) Received: from MAIL1.WPI.EDU (MAIL1.WPI.EDU [130.215.36.91]) by ietfa.amsl.com (Postfix) with ESMTP id 2879AE0663 for ; Wed, 11 May 2011 16:59:54 -0700 (PDT) Received: from MAIL1.WPI.EDU (MAIL1.WPI.EDU [130.215.36.91]) by MAIL1.WPI.EDU (8.14.5.Gamma0/8.14.5.Gamma0) with ESMTP id p4BNxr8q001778 for ; Wed, 11 May 2011 19:59:53 -0400 X-DKIM: Sendmail DKIM Filter v2.8.3 MAIL1.WPI.EDU p4BNxr8q001778 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wpi.edu; s=_dkim; t=1305158393; bh=+XndnnI9+/txbF4M6ja+0oWXFSrEhx28yW5SFQtYxtE=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=vHN06MG8WThdeTKH2xtCJsOy+WL2Cr6LrpfTkm9trFAVAOwY/2bs/F4479iCY4IHY GuXXxPgxJeelIr9V7abPqp93Dq5125XmyeTxLO6tnHfQRs5K/jbgf1OAZU2arga5+3 7+wjfSMU8Zk1ZjARNBO6Mi8juR9qKN9sSE9gR9Wk= Received: from SMTP.WPI.EDU (SMTP.WPI.EDU [130.215.36.186]) by MAIL1.WPI.EDU (8.14.5.Gamma0/8.14.5.Gamma0) with ESMTP id p4BNxrMU001775 for ; Wed, 11 May 2011 19:59:53 -0400 Received: from erwin.wpi.edu (ERWIN.WPI.EDU [130.215.201.24]) by SMTP.WPI.EDU (8.14.4/8.14.4) with ESMTP id p4BNxqCs017230; Wed, 11 May 2011 19:59:52 -0400 (envelope-from fs@wpi.edu) Received: from [192.168.1.116] (68-184-39-204.dhcp.oxfr.ma.charter.com [68.184.39.204]) (authenticated bits=0) by erwin.wpi.edu (8.14.4/8.14.2) with ESMTP id p4BNxpcV014868 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 11 May 2011 19:59:51 -0400 Message-ID: <4DCB22EC.6070100@wpi.edu> Date: Wed, 11 May 2011 19:59:40 -0400 From: Frank Sweetser User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: dhcwg@ietf.org References: <4DC8579E.7080606@gmail.com> In-Reply-To: <4DC8579E.7080606@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=XXXII, Probability=32%, Report=' SXL_IP_DYNAMIC 3, TO_IN_SUBJECT 0.5, BODY_SIZE_6000_6999 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, FROM_EDU_TLD 0, RDNS_DYNAMIC 0, RDNS_GENERIC_POOLED 0, RDNS_POOLED 0, RDNS_SUSP 0, RDNS_SUSP_GENERIC 0, RDNS_SUSP_SPECIFIC 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __C230066_P1_2 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MOZILLA_MSGID 0, __PHISH_SPEAR_STRUCTURE_1 0, __RDNS_DYNAMIC_1 0, __RDNS_POOLED_9 0, __SANE_MSGID 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __URI_NS , __USER_AGENT 0' Subject: Re: [dhcwg] DHCPv6 Failover - volunteers needed 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, 11 May 2011 23:59:56 -0000 On 5/9/2011 5:07 PM, Tomasz Mrugalski wrote: > Dear group, > DHCPv6 failover was mentioned a couple of times on mailing list and > other places, but it looks like no real work started in that area. I'd > like to change that. > > I'm looking for people, who would like to be involved in DHCPv6 failover > work. Ted Lemon and John Brzozowski are supporting this effort. If you > are interested, please respond to the list or contact me directly. I'd be happy to at least offer a few comments. I'm coming from the perspective of an enterprise network administrator, so I'm sure there are plenty of scenarios I'm not considering, but this is at least one set of concerns and opinions. > My high level plan is to write DHCPv6 failover requirements document > first. This will let us avoid problems encountered with v4 failover > standardization attempts - it started as relatively simple draft, but > people kept adding extra features and it became something else than > originally envisaged. That would be very short document that would > contain definitions and enumerate goals of this work, what is relevant > and what is outside of scope. > > If you think that having such requirements list as a separate document > is a bad idea, we could consider incorporating it into the main failover > draft, but in my opinion having separate documents is cleaner and easier > to maintain. > > Here are initial questions that we should consider, sometimes with my > first proposed answers. > > 1. Primary goal is to define failover protocol, so rough failover > definition is needed. DHCPv6 failover is an ability of one peer (DHCPv6 > server) to continue serving leases provided by another peer, without > affecting clients' connectivity. In my ideal world, failover would imply the opposite of the famous Leslie Lamport quote - the failure of a machine I didn't even know existed, makes no difference to the machine I'm using. Server peer leases is obviously a good start. > 2. Do we want high availability? Yes, YES, /YES/. On a large network like mine (~10k hosts, small support staff, lots of self-administered student owned machines), where hardcoding any large class of device is impractical, if DHCP doesn't work, then nothing works. There are other ways of mitigating this (hardcoding servers, using exceptionally long leases), but lack of DHCP services still has a huge operational impact. > 4. Do we want load balancing? Others will huge networks may want this, but for my money, servers are cheap and fast enough that it's easy to just throw more iron at a problem. 3GHz CPUs, 10Gbit network interfaces, and server class SSDs can allow you process a silly amount of DHCP transactions without worrying too much about explicit load balancing. > 6. Should geographically distributed failover be taken into consideration? Yes. For example, I have a handful of semi-remote locations that justify installing a lower end DHCP server in the building, but pair with the beefier ones back on the main campus. This gives me good redundancy in the building, without having to buy a second dedicated server. > 3. If we want HA/LB/geo-failover, should it be defined in the core spec > or as a separate document? Keeping them in single document can be easier > in the beginning, but then can bloat the document quickly. As I said, I'd prioritize HA over load balancing. As for geo distribution, I'm curious - how do you see that differing from vanilla HA? > 4. Should failover also cover prefix delegations or addresses only? > My proposal is both address and prefixes. PD is a core feature of > DHCPv6, so we can't pretend that it doesn't exist. PD is a must. For the near future we're only looking at doing addresses, but yeah, ignoring prefixes now just invites more after the fact duct tape patching later on. > 5. How many peers should this protocol support? > My opinion is that 2 is enough. While having several peers would be > great, the difficulty of synchronizing bigger number of peers than a > pair may be very difficult. Going from one to two, and removing a single point of failure, is certainly a much larger jump than going from two to three (to four, to five...). That said, I've had cases where I've had less redundancy than I'd prefer because I'm limited to only failover pairs. It's nothing I'm losing any sleep over, but the ability to define a pool of fully equivalent masters would make some of my design decisions a bit simpler. Some of the nosql databases have been doing a lot of work on multi-master replication. Would it be worth using or stealing from one of them, like apache casandra? > After we agree on answers to those questions, we may start thinking > about how should the actual handover protocol will work. Two > introductory questions for now: > > 6. Should we adopt DHCPv4 failover > (http://tools.ietf.org/id/draft-ietf-dhc-failover-12.txt) as a starting > point (or at least based on the same concept)? Note that this work > started in 1997, but was eventually abandoned in 2003, so using the > latest revision as a starting point may not be the best idea. > > 7. Significant part of the failover will be synchronization between > peers, including transmitting selected/all leases. There is similar > mechanism used in leasequery (RFC5007) and bulk leasequery (RFC5460). Do > we want to reuse/extend that or define something new? > > Feel free to add other questions to the list. > > I'm looking forward to your comments and suggestions, > > Tomek Mrugalski > ISC > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg -- Frank Sweetser fs at wpi.edu | For every problem, there is a solution that WPI Senior Network Engineer | is simple, elegant, and wrong. - HL Mencken GPG fingerprint = 6174 1257 129E 0D21 D8D4 E8A3 8E39 29E3 E2E8 8CEC From jouni.korhonen@nsn.com Wed May 11 13:15:04 2011 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 A17E2E0717 for ; Wed, 11 May 2011 13:15:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iwUC6unckrEj for ; Wed, 11 May 2011 13:15:03 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 97FCFE069C for ; Wed, 11 May 2011 13:15:03 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p4BKEpNs028389 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 11 May 2011 22:14:51 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p4BKEnFU022007; Wed, 11 May 2011 22:14:51 +0200 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 May 2011 22:14:48 +0200 Received: from 10.144.200.111 ([10.144.200.111]) by FIESEXC035.nsn-intra.net ([10.159.0.182]) via Exchange Front-End Server demuexc023.nsn-intra.net ([10.150.128.36]) with Microsoft Exchange Server HTTP-DAV ; Wed, 11 May 2011 20:14:48 +0000 User-Agent: Microsoft-Entourage/12.29.0.110113 Date: Wed, 11 May 2011 23:14:46 +0300 From: Jouni Korhonen To: ext Ole Troan , Tomasz Mrugalski Message-ID: Thread-Topic: [dhcwg] WGLC on draft-ietf-dhc-pd-exclude-01 Thread-Index: AcwQGBJZyihx5VrJykmk2ZbuG5zhWg== In-Reply-To: <969A86F7-D2B4-482D-8E2F-A845DB53D09F@employees.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 11 May 2011 20:14:48.0856 (UTC) FILETIME=[140D0980:01CC1018] X-Mailman-Approved-At: Wed, 11 May 2011 18:13:38 -0700 Cc: "dhcwg@ietf.orgWG WG" Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-pd-exclude-01 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, 11 May 2011 20:15:04 -0000 Hi, On 5/11/11 10:16 AM, "ext Ole Troan" wrote: > Tomek, > > thanks for good comments! +1 >>> We had a last call on this prior to the Prague meeting, and there was >>> work done off list, but no responses on-list. If you support this >>> work, please indicate that you support it. If you oppose the work, >>> please provide suggestions, comments, or reasons why it's entirely a >>> bad idea. >> I read and support this draft. >> >> I know that it's way past dead-line, so feel free to ignore my comments. >> >> Here are my comments. If it is not too late, you could consider them: >> >> 1. Section 1: >> "single aggregatable route/prefix has to represents one customer" >> => remove "has to" or change represents to represent. > > agree. Will change to: "single aggregatable route/prefix has to represent one customer" > >> 2. Section 4.1 >> "The requesting router MUST NOT assign the excluded prefix to any of its >> downstream interfaces.". Is this implicit suggestion that assigning >> excluded prefix to upstream interface is ok? That would be against >> RFC3633, Section 12.1 that forbids that. This is probably ok, but then >> "updates: 3633" should be added to the preamble (and possibly a simple >> clarification). However, if the excluded prefix is handled in some >> different way (like SLAAC), then it is ok in current form. > > we are basically trying to say that the excluded prefix is not delegated to > the requesting router. > that means the requesting router has no 'ownership' of that prefix and cannot > assign it to any interface. > obviously the delegating router can advertise that prefix in an RA and then > the requesting router can use SLAAC to configure an address out of the prefix. > do you think this needs clarification, if so suggested text? > >> 3. Section 4.2 >> "The OPTION_PD_EXCLUDE option MUST be located before the possible Status >> Code option in the IAprefix-options field." Why forcing to use specific >> order? DHCPv6 does not impose any restrictions regarding sequence, in >> which options appear in a message or within other options. There's good >> reason for that - implementations may keep the options in structures >> other than simple lists or vector, like hash tables. Enforcing any >> specific order would be troublesome in that case. I propose to remove >> this sentence. > > I tend to agree, what do my co-authors think? > can't remember why we put this in the first place... I put this there for some reason. Now I have been trying to remember what was the original reason.. without success. Therefore, if I cannot even remember it anymore there is no reason to have the MUST there. Ok to remove the sentence. > >> 4. Section 5.1 >> My understanding was that requesting router is supposed to include >> PD_EXCLUDE in ORO in SOLICIT, REQUEST, RENEW, REBIND and CONFIRM. Yet, >> there is only Solicit message mentioned in the first sentence of 5.1. >> Remaining message types should probably be mentioned as well. > > what about: > > If the requesting router implements the solution described in Section 4.1 > then the requesting router SHOULD include the OPTION_PD_EXCLUDE option code in > the OPTION_ORO option in DHCP messages > as described in section 22.7 of RFC3315. Ole's text looks good to me. > >> 5. PD_EXCLUDE option is going to be delivered in IAPREFIX that is >> located in IA_PD (not in the message options field), but draft says that >> requesting router should request PD_EXCLUDE in ORO placed in message >> options field. Wouldn't it be more appropriate to put second instance of >> ORO (with PD_EXCLUDE code) in IA_PD sent by requesting router? You may >> consider reading draft-mrugalski-dhc-dhcpv6-suboptions and follow its >> suggestions, if you that they are reasonable. > > good point, I wasn't aware of this. I also think including the ORO at the > correct option 'scope' is better. > any objections to that? I have no strong opinion here. However, options that are used and what we also define have a flat option number space, thus scoping does not bring much advantage as we are not defining a sub-option per se. I see no compelling reason to change the current text/behavior. - Jouni > > cheers, > Ole From ichiroumakino@gmail.com Thu May 12 01:00:56 2011 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 0046BE0730 for ; Thu, 12 May 2011 01:00:56 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id clIQJFIDp9Uk for ; Thu, 12 May 2011 01:00:55 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA38E0724 for ; Thu, 12 May 2011 01:00:54 -0700 (PDT) Received: by wyb29 with SMTP id 29so1127713wyb.31 for ; Thu, 12 May 2011 01:00:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=0GBqs0/q8BfWuZnsAt7ZlQ+FKmfxC3e7Dk8V89nI7+8=; b=PzQqxskhElySn/KiQDM7Afcu63il+UqfFgU8z8ajTSIzFNoO+rBOMAWnOkAw3Frmpu lO87pycWLFkUNgk+TpR0OYxdxRfpuP4AK5vNN49j9MA3LJ1j/rN+Tn/47IEpTVF/cGEF KwySsqXES56XJF9hdgQUC+eDlJH56+8g4To84= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=whYSiVK1Hwd0XM6F3QdXiKFrdncF0rn/aS686mvC/ppzPuf0dtFfHE+j2oMNGenZnB 7OCfnYA2cdfAdIkGDCXX1yJ+u1g+CydPpLIE3pi1pDi9Xm5r7bURx3bNN+AfAV1LMaqI 3WMJkroQ6jqV06Fs29px9oKfW2ro5jay7MC0U= Received: by 10.216.58.207 with SMTP id q57mr3779959wec.63.1305187254162; Thu, 12 May 2011 01:00:54 -0700 (PDT) Received: from dhcp-osl-vl300-64-103-53-245.cisco.com (dhcp-osl-vl300-64-103-53-245.cisco.com [64.103.53.245]) by mx.google.com with ESMTPS id g58sm466578wen.44.2011.05.12.01.00.52 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 12 May 2011 01:00:52 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: <68614430-1044-45EE-9B64-354284B13D87@gmail.com> Date: Thu, 12 May 2011 10:00:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <94200415-3C9D-4C61-88AB-42A6D0E11649@nominum.com> <4DC864D1.8010101@gmail.com> <20110511184158.GB4138@shell-too.nominum.com> <68614430-1044-45EE-9B64-354284B13D87@gmail.com> To: jouni korhonen X-Mailer: Apple Mail (2.1084) Cc: dhcwg@ietf.org Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-pd-exclude-01 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, 12 May 2011 08:00:56 -0000 >> It is not wrong as-is, but I think it is a bit strange/confusing that >> OPTION_PD_EXCLUDE (in 4.2. Prefix Exclude Option) is defined in such >> a way that the "IPv6 subnet ID" is a suffix appended to the >> 'OPTION_IAPREFIX prefix-length', except maybe not ust a suffix = because >> it has to be octet-aligned so it might include some of the bits of >> 'OPTION_IAPREFIX prefix-length'. >>=20 >> I misunderstood the definition in section 4.2 until I read the >> example at the end. >>=20 >> It also seems like a strange way to define option data. Does anything >> else use this way of declaring a sub-prefix? >>=20 >> It would seem to me to have two pros: >>=20 >> 1) It saves some number of bytes of option space. >> 2) It ensures that the OPTION_PD_EXCLUDE prefix is contained >> in the OPTION_IAPREFIX prefix[*]. >>=20 >> [*] except if octet-alignment requires replication of >> the final few bits of the OPTION_IAPREFIX prefix, >> in which case those could be incorrectly included >> as different bit values, presumably, so it doesn't >> really even guarantee #2, does it? >=20 > I don't get the issue you are seeing here. Could you give an example = of an incorrect case? no, I think that's a misunderstanding there is no replication of the = bits from IAPREFIX. sounds like an argument for making that text clearer though. >> It would seem to have 2 cons: >>=20 >> 1) It is hard to understand. >> 2) I think implementors may implement it incorrectly, causing >> interoperability issues. >>=20 >> Given that pro #2 is a weak assurance and pro #1 only means saving a >> few bytes (how much does that really matter? I would say not at all), >> I think the cons significantly outweigh the pros. >>=20 >> I would suggest that OPTION_PD_EXCLUDE ought to include the full >> prefix to exclude. >=20 > I.e. back to formatting we still had in = draft-korhonen-dhc-pd-exclude-01.. until it got changed because of the = concerns raised that are here listed as pros 1) and 2). I am OK going = back to old encoding. I think the current coding is very elegant. I don't care so much about = saving the few bytes. but avoiding having redundant information in the = option saves on both lots of text describing the corner cases (e.g. the = exclude isn't part of the iaprefix and so on), and it saves on = implementations having to do all those checks. as an example of what we = would get into. what should an implementation do if it gets a exclude = prefix that isn't part of the ia_prefix? send a Decline option (which is = very specific to address assignment, and would have to be redefined). cheers, Ole From leaf.y.yeh@huawei.com Thu May 12 01:08:50 2011 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 D73A0E0744 for ; Thu, 12 May 2011 01:08:50 -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=[AWL=-1.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id krIaT6kLYFCS for ; Thu, 12 May 2011 01:08:50 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 1E240E070C for ; Thu, 12 May 2011 01:08:47 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LL200HZ5P9661@szxga05-in.huawei.com> for dhcwg@ietf.org; Thu, 12 May 2011 16:07:55 +0800 (CST) Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LL2006QRP8PDS@szxga05-in.huawei.com> for dhcwg@ietf.org; Thu, 12 May 2011 16:07:54 +0800 (CST) Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 12 May 2011 16:07:40 +0800 Received: from SZXEML514-MBX.china.huawei.com ([169.254.2.14]) by szxeml403-hub.china.huawei.com ([169.254.173.75]) with mapi id 14.01.0270.001; Thu, 12 May 2011 16:07:28 +0800 Date: Thu, 12 May 2011 08:07:27 +0000 From: Leaf yeh In-reply-to: X-Originating-IP: [10.70.39.133] To: Ted Lemon Message-id: MIME-version: 1.0 Content-type: text/plain; charset=Windows-1252 Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: [dhcwg] WG adoption of draft-asati-dhc-relay-agent-config-00 Thread-index: AcvwvmvXzCHd+ukFSkSNyX8FCnzm+gYI7ONAAZfrWYAAEvCUcAABKYoAACyfDpA= X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <067E6CE33034954AAC05C9EC85E2577C04905E0E@XMB-RCD-111.cisco.com> <9105F293-1C25-4546-85B0-CF1E1A035CD9@nominum.com> Cc: "dhcwg@ietf.org" , Bernie Volz Subject: Re: [dhcwg] WG adoption of draft-asati-dhc-relay-agent-config-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, 12 May 2011 08:08:51 -0000 Not sure the separated drafts will get the solid reasons for each of both. 1. Do we really need a new option with new structure or architecture for the relay configuration in the case of IPv4 & IPv6? 2. Would the 2nd draft raise a reasonable solution for BGP/MPLS IP/VPN (RFC4364) per the section 1 & 3 of this draft (draft-asati)? Best Regards, Leaf -----Original Message----- From: Ted Lemon [mailto:Ted.Lemon@nominum.com] Sent: Wednesday, May 11, 2011 8:17 PM To: Leaf yeh Cc: dhcwg@ietf.org; Bernie Volz Subject: Re: [dhcwg] WG adoption of draft-asati-dhc-relay-agent-config-00 On May 10, 2011, at 11:50 PM, Leaf yeh wrote: > Ted - I will admit that in simply reading the draft, it does seem like it's not actually doing anything, ... It occurs to me that one way to address this concern would be to write a second draft that describes a suboption that would be a payload for this mechanism. The two drafts, presented together, would make more sense than this draft all on its own. From volz@cisco.com Thu May 12 06:10:44 2011 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 37ABEE0735 for ; Thu, 12 May 2011 06:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.319 X-Spam-Level: X-Spam-Status: No, score=-10.319 tagged_above=-999 required=5 tests=[AWL=0.280, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4zshiEdhs5KC for ; Thu, 12 May 2011 06:10:40 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by ietfa.amsl.com (Postfix) with ESMTP id 4A398E0793 for ; Thu, 12 May 2011 06:10:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=1529; q=dns/txt; s=iport; t=1305205840; x=1306415440; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=LEuohZDfaYqh+nK4RvMnScVjAtTseF9ySkXpEUUJaoY=; b=el+BIsY6vmuRF/PTD5lPeezYOuVrX4qEpzLvTrCk0ecwD2vBGHw/KPRp 9V6AhmBsjcnbWCOM7X2bJINooFHgWbPjfWO+veahoV5nwNGADIbvvGLOX qFLed32kpvmb4SSE5lJEu4BZ27T0BgIy26ddG/UgioPnjAwJiQXM9MTs7 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj0BAAjcy02tJV2d/2dsb2JhbACXPo41d6lAnjGGFQSGSY1jilY X-IronPort-AV: E=Sophos;i="4.64,358,1301875200"; d="scan'208";a="356032983" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by sj-iport-5.cisco.com with ESMTP; 12 May 2011 13:10:39 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id p4CDAdf0007762; Thu, 12 May 2011 13:10:39 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); Thu, 12 May 2011 08:10:39 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 May 2011 08:10:38 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] WG adoption of draft-asati-dhc-relay-agent-config-00 Thread-Index: AcvwvmvXzCHd+ukFSkSNyX8FCnzm+gYI7ONAAZfrWYAAEvCUcAABKYoAACyfDpAAGEelcA== References: <067E6CE33034954AAC05C9EC85E2577C04905E0E@XMB-RCD-111.cisco.com> <9105F293-1C25-4546-85B0-CF1E1A035CD9@nominum.com> From: "Bernie Volz (volz)" To: "Leaf yeh" , "Ted Lemon" X-OriginalArrivalTime: 12 May 2011 13:10:39.0112 (UTC) FILETIME=[FD3C0880:01CC10A5] Cc: dhcwg@ietf.org Subject: Re: [dhcwg] WG adoption of draft-asati-dhc-relay-agent-config-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, 12 May 2011 13:10:44 -0000 I'd prefer one draft - not two. When Option 82 for DHCPv4 was defined, it included 2 suboptions. More were added later. Why do it in two drafts - I don't understand the value? It is much clearer if one document defines all of this. - Bernie -----Original Message----- From: Leaf yeh [mailto:leaf.y.yeh@huawei.com]=20 Sent: Thursday, May 12, 2011 4:07 AM To: Ted Lemon Cc: dhcwg@ietf.org; Bernie Volz (volz) Subject: RE: [dhcwg] WG adoption of draft-asati-dhc-relay-agent-config-00 Not sure the separated drafts will get the solid reasons for each of both.=20 1. Do we really need a new option with new structure or architecture for the relay configuration in the case of IPv4 & IPv6? 2. Would the 2nd draft raise a reasonable solution for BGP/MPLS IP/VPN (RFC4364) per the section 1 & 3 of this draft (draft-asati)? Best Regards, Leaf -----Original Message----- From: Ted Lemon [mailto:Ted.Lemon@nominum.com]=20 Sent: Wednesday, May 11, 2011 8:17 PM To: Leaf yeh Cc: dhcwg@ietf.org; Bernie Volz Subject: Re: [dhcwg] WG adoption of draft-asati-dhc-relay-agent-config-00 On May 10, 2011, at 11:50 PM, Leaf yeh wrote: > Ted - I will admit that in simply reading the draft, it does seem like it's not actually doing anything, ... It occurs to me that one way to address this concern would be to write a second draft that describes a suboption that would be a payload for this mechanism. The two drafts, presented together, would make more sense than this draft all on its own. From Stephen.Jacob@nominum.com Thu May 12 11:12:53 2011 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 EB6DAE06A1 for ; Thu, 12 May 2011 11:12:53 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id phwBkPP2v1hq for ; Thu, 12 May 2011 11:12:52 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by ietfa.amsl.com (Postfix) with ESMTP id 98CA3E06C6 for ; Thu, 12 May 2011 11:12:52 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKTcwjISxBMlMvY8x9bUrTbLk3znJ0YsNE@postini.com; Thu, 12 May 2011 11:12:52 PDT Received: by shell-too.nominum.com (Postfix, from userid 11053) id 3BD7D1B8595; Thu, 12 May 2011 11:12:49 -0700 (PDT) Date: Thu, 12 May 2011 11:12:49 -0700 From: Stephen Jacob To: Ole Troan Message-ID: <20110512181249.GA12824@shell-too.nominum.com> Mail-Followup-To: Ole Troan , jouni korhonen , Stephen Jacob , dhcwg@ietf.org References: <94200415-3C9D-4C61-88AB-42A6D0E11649@nominum.com> <4DC864D1.8010101@gmail.com> <20110511184158.GB4138@shell-too.nominum.com> <68614430-1044-45EE-9B64-354284B13D87@gmail.com> 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] WGLC on draft-ietf-dhc-pd-exclude-01 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, 12 May 2011 18:12:54 -0000 On Thu, May 12, 2011 at 10:00:49AM +0200, Ole Troan wrote: > >> It would seem to me to have two pros: > >> > >> 1) It saves some number of bytes of option space. > >> 2) It ensures that the OPTION_PD_EXCLUDE prefix is contained > >> in the OPTION_IAPREFIX prefix[*]. > >> > >> [*] except if octet-alignment requires replication of > >> the final few bits of the OPTION_IAPREFIX prefix, > >> in which case those could be incorrectly included > >> as different bit values, presumably, so it doesn't > >> really even guarantee #2, does it? > > > > I don't get the issue you are seeing here. Could you give an example > > of an incorrect case? > > no, I think that's a misunderstanding there is no replication of the > bits from IAPREFIX. sounds like an argument for making that text > clearer though. See below. I believe I misunderstood. > >> It would seem to have 2 cons: > >> > >> 1) It is hard to understand. > >> 2) I think implementors may implement it incorrectly, causing > >> interoperability issues. > >> > >> Given that pro #2 is a weak assurance and pro #1 only means saving a > >> few bytes (how much does that really matter? I would say not at all), > >> I think the cons significantly outweigh the pros. > >> > >> I would suggest that OPTION_PD_EXCLUDE ought to include the full > >> prefix to exclude. > > > > I.e. back to formatting we still had in > > draft-korhonen-dhc-pd-exclude-01.. until it got changed because of > > the concerns raised that are here listed as pros 1) and 2). I am OK > > going back to old encoding. > > I think the current coding is very elegant. I don't care so much about > saving the few bytes. but avoiding having redundant information in the > option saves on both lots of text describing the corner cases (e.g. > the exclude isn't part of the iaprefix and so on), and it saves on > implementations having to do all those checks. as an example of what > we would get into. what should an implementation do if it gets a > exclude prefix that isn't part of the ia_prefix? send a Decline option > (which is very specific to address assignment, and would have to be > redefined). I may have misunderstood. I interpreted it as saying (in the bit about octet-alignment) that if you had: Prefix: abcd:ff00::/24 Exclude prefix: abcd:ff11::/16 the value in the OPTION_PD_EXCLUDE prefix field would have to be 0xff11, thus reproducing a minimum number of bits of IAPREFIX to byte-align the additional bits specific to the exclude prefix. I now think what it is saying is that the OPTION_PD_EXCLUDE prefix field would be 0x1100 (left-shifted to the nearest octet boundary; padded) which eliminates my concern about pro #2 not being reliable. Elegant and simple is great. Elegant and confusing is not. My fear is two-fold: (i) It will be hard to understand and thus people will implement it incorrectly either through not understanding what they were meant to do or from coding errors in the implementation. (ii) It means that a server implementing the option has to define a new option format with a rather strange new relationship between the fields 'prefix-len' and 'IPv6 subnet ID'. The first can probably be addressed by adding text to clarify. It is possible that I should have figured out what it really meant on the first reading, but if I did so then I think it is not unreasonable to extrapolate that others might. I'm still not happy about (ii), but if the consensus is that the advantages afforded by it outweigh my concerns, fair enough. Regards, Stephen -- Stephen Jacob | Stephen.Jacob@nominum.com | +1 650 381 6051 Nominum, Inc. | http://www.nominum.com/ | +1 650 381 6000 From jouni.nospam@gmail.com Thu May 12 12:17:21 2011 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 09A85E0718 for ; Thu, 12 May 2011 12:17:21 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VGrBrWqFmtnb for ; Thu, 12 May 2011 12:17:20 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 53FBEE0706 for ; Thu, 12 May 2011 12:17:20 -0700 (PDT) Received: by eye13 with SMTP id 13so660310eye.31 for ; Thu, 12 May 2011 12:17:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=NM6SadHAyIRUoCIwdJFJtA6syUzQnVjYFn3toJPxPoo=; b=gzXWLh+GVH/tqbn9K2V00/htq9ZfWN/PDF/bpcFbUviB4Cq2d8DhoJFoifvISC4Ipk wi5FvVkqfPdcddDLLVO3I9WSFHy7KEonXpYqihXr+7fz+FQohirgkuKknpiDKeouHs8M LOZ59ayIl1a4n4DdfzCS/mqS3+C1pTLPXa47I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=gX2ioe3rvA6Ok6uFiPiwG78amZs+A4ItH+1J+3cvw8eymkl1KfK9W4NzOz3nMHVBRv WWzV9TKLi81s90290A4wWf1aTKTeEtDtBLH8PaBk6owhkoCgt3cWCUzBSPyaPCHJpZOY sDmMxPDP8KzI8PcbdGfnk3urvsK47aSlFP7yc= Received: by 10.14.52.132 with SMTP id e4mr324294eec.173.1305227839387; Thu, 12 May 2011 12:17:19 -0700 (PDT) Received: from a88-114-65-87.elisa-laajakaista.fi (a88-114-65-87.elisa-laajakaista.fi [88.114.65.87]) by mx.google.com with ESMTPS id x12sm910406eeh.26.2011.05.12.12.17.17 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 12 May 2011 12:17:18 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <20110512181249.GA12824@shell-too.nominum.com> Date: Thu, 12 May 2011 22:17:15 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <94200415-3C9D-4C61-88AB-42A6D0E11649@nominum.com> <4DC864D1.8010101@gmail.com> <20110511184158.GB4138@shell-too.nominum.com> <68614430-1044-45EE-9B64-354284B13D87@gmail.com> <20110512181249.GA12824@shell-too.nominum.com> To: Stephen Jacob X-Mailer: Apple Mail (2.1082) Cc: dhcwg@ietf.org Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-pd-exclude-01 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, 12 May 2011 19:17:21 -0000 Stephen, > I may have misunderstood. I interpreted it as saying (in the bit about > octet-alignment) that if you had: > Prefix: abcd:ff00::/24 > Exclude prefix: abcd:ff11::/16 You cannot exclude a shorter prefix than you delegate. Based on the = above example you would actually be excluding abcd:ff11::/32. That would = result to a subnet-id 0x11 and consume one octet. - Jouni= From Stephen.Jacob@nominum.com Thu May 12 12:25:48 2011 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 EF869E0706 for ; Thu, 12 May 2011 12:25:48 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N0rT-P1g6u8E for ; Thu, 12 May 2011 12:25:48 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB4DE0767 for ; Thu, 12 May 2011 12:25:47 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKTcw0OufUA5L/teiVZ1iiEG1zOFhflvP5@postini.com; Thu, 12 May 2011 12:25:48 PDT Received: by shell-too.nominum.com (Postfix, from userid 11053) id DCEC2F8015; Thu, 12 May 2011 12:25:45 -0700 (PDT) Date: Thu, 12 May 2011 12:25:45 -0700 From: Stephen Jacob To: jouni korhonen Message-ID: <20110512192545.GA16742@shell-too.nominum.com> Mail-Followup-To: jouni korhonen , Stephen Jacob , Ole Troan , dhcwg@ietf.org References: <94200415-3C9D-4C61-88AB-42A6D0E11649@nominum.com> <4DC864D1.8010101@gmail.com> <20110511184158.GB4138@shell-too.nominum.com> <68614430-1044-45EE-9B64-354284B13D87@gmail.com> <20110512181249.GA12824@shell-too.nominum.com> 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] WGLC on draft-ietf-dhc-pd-exclude-01 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, 12 May 2011 19:25:49 -0000 On Thu, May 12, 2011 at 10:17:15PM +0300, jouni korhonen wrote: > Stephen, > > > I may have misunderstood. I interpreted it as saying (in the bit about > > octet-alignment) that if you had: > > Prefix: abcd:ff00::/24 > > Exclude prefix: abcd:ff11::/16 > > You cannot exclude a shorter prefix than you delegate. Based on the > above example you would actually be excluding abcd:ff11::/32. That > would result to a subnet-id 0x11 and consume one octet. Oops! I meant /32. Typo. Regards, Stephen -- Stephen Jacob | Stephen.Jacob@nominum.com | +1 650 381 6051 Nominum, Inc. | http://www.nominum.com/ | +1 650 381 6000 From mellon@fugue.com Fri May 13 11:21:08 2011 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 BF9A4E0764 for ; Fri, 13 May 2011 11:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.732 X-Spam-Level: X-Spam-Status: No, score=-1.732 tagged_above=-999 required=5 tests=[AWL=0.866, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4l7DOCX2jEwW for ; Fri, 13 May 2011 11:21:07 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id E3B80E0679 for ; Fri, 13 May 2011 11:21:07 -0700 (PDT) Received: from [10.1.10.17] (173-162-214-218-NewEngland.hfc.comcastbusiness.net [173.162.214.218]) by toccata.fugue.com (Postfix) with ESMTPSA id CB68C34E419C; Fri, 13 May 2011 14:21:39 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1222) Content-Type: multipart/alternative; boundary="Apple-Mail=_85F0AD62-9ED7-4057-B306-9E914240C38A" From: Ted Lemon In-Reply-To: Date: Fri, 13 May 2011 14:21:03 -0400 Message-Id: <62B5123D-3283-4F8B-A6CF-3BCEC6FE86C9@fugue.com> References: <99DF3B00-534F-4CA7-879B-8B64531C2513@nominum.com> To: Andre Kostur X-Mailer: Apple Mail (2.1222) Cc: dhcwg@ietf.org, "Ralph Droms \(rdroms\)" , "Bernie Volz \(volz\)" , "Kim Kinnear \(kkinnear\)" Subject: Re: [dhcwg] FYI - A note regarding DHCPv6 from Interop 2011 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, 13 May 2011 18:21:08 -0000 --Apple-Mail=_85F0AD62-9ED7-4057-B306-9E914240C38A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On May 11, 2011, at 7:46 PM, Andre Kostur wrote: > At least on my Windows machine, the DUID is based on the MAC address. = DUID-LLT. Yes, but it's based on the mac address of the machine at install time. = If you then clone the machine, the DUID-LLT will be cloned from the = original, so it won't contain the mac address of an interface on the = clone. --Apple-Mail=_85F0AD62-9ED7-4057-B306-9E914240C38A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii At least on = my Windows machine, the DUID is based on the MAC address. =  DUID-LLT.

Yes, but = it's based on the mac address of the machine at install time.   If = you then clone the machine, the DUID-LLT will be cloned from the = original, so it won't contain the mac address of an interface on the = clone.

= --Apple-Mail=_85F0AD62-9ED7-4057-B306-9E914240C38A-- From Ted.Lemon@nominum.com Fri May 13 11:26:06 2011 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 82712E07F3 for ; Fri, 13 May 2011 11:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.332 X-Spam-Level: X-Spam-Status: No, score=-106.332 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8WMVGL1ktQ+y for ; Fri, 13 May 2011 11:26:05 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id 3D108E07F9 for ; Fri, 13 May 2011 11:26:05 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKTc13vInEXJvGCpAzfOPv0ZLOaTZS+xJp@postini.com; Fri, 13 May 2011 11:26:05 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 521341B85D9 for ; Fri, 13 May 2011 11:26:04 -0700 (PDT) Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 46E84190052; Fri, 13 May 2011 11:26:04 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from vpna-148.vpn.nominum.com (64.89.227.148) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 13 May 2011 11:26:03 -0700 MIME-Version: 1.0 (Apple Message framework v1222) Content-Type: text/plain; charset="us-ascii" From: Ted Lemon In-Reply-To: Date: Fri, 13 May 2011 14:26:00 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <067E6CE33034954AAC05C9EC85E2577C04905E0E@XMB-RCD-111.cisco.com> <9105F293-1C25-4546-85B0-CF1E1A035CD9@nominum.com> To: Leaf yeh X-Mailer: Apple Mail (2.1222) Cc: "dhcwg@ietf.org" , Bernie Volz Subject: Re: [dhcwg] WG adoption of draft-asati-dhc-relay-agent-config-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, 13 May 2011 18:26:06 -0000 On May 12, 2011, at 4:07 AM, Leaf yeh wrote: > 1. Do we really need a new option with new structure or architecture = for the relay configuration in the case of IPv4 & IPv6? > 2. Would the 2nd draft raise a reasonable solution for BGP/MPLS = IP/VPN (RFC4364) per the section 1 & 3 of this draft (draft-asati)? I think the use case addressed by the draft does require some enabling = extension. My suggestion was to put an ORO in the Relay-Forw message = and have the server send back options that way, rather than defining a = new container. Although having said that, I now feel the need to step back a pace. It = doesn't actually make sense to piggyback this functionality on top of a = DHCP client message. In any case, none of this is germane to the question of whether or not = this is work the working group ought to do. Part of the work of the = working group is figuring out the right solution to the problem. The = question in the call for adoption is, do we think this is work that is = worth doing? From Ted.Lemon@nominum.com Fri May 13 11:31:49 2011 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 0E7ADE084B for ; Fri, 13 May 2011 11:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.37 X-Spam-Level: X-Spam-Status: No, score=-106.37 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tl8m7U8PLKDZ for ; Fri, 13 May 2011 11:31:48 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id 240E8E084A for ; Fri, 13 May 2011 11:31:47 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKTc15EyuiWxKAcJZVDjHyFYjYlI4Dv5zo@postini.com; Fri, 13 May 2011 11:31:48 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 070D01B85DD for ; Fri, 13 May 2011 11:31:47 -0700 (PDT) Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 01060190052; Fri, 13 May 2011 11:31:47 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from vpna-148.vpn.nominum.com (64.89.227.148) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 13 May 2011 11:31:46 -0700 MIME-Version: 1.0 (Apple Message framework v1222) Content-Type: text/plain; charset="us-ascii" From: Ted Lemon In-Reply-To: Date: Fri, 13 May 2011 14:31:42 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <94200415-3C9D-4C61-88AB-42A6D0E11649@nominum.com> <4DC864D1.8010101@gmail.com> <20110511184158.GB4138@shell-too.nominum.com> <68614430-1044-45EE-9B64-354284B13D87@gmail.com> To: Ole Troan X-Mailer: Apple Mail (2.1222) Cc: dhcwg@ietf.org Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-pd-exclude-01 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, 13 May 2011 18:31:49 -0000 On May 12, 2011, at 4:00 AM, Ole Troan wrote: > I think the current coding is very elegant. I don't care so much about = saving the few bytes. but avoiding having redundant information in the = option saves on both lots of text describing the corner cases (e.g. the = exclude isn't part of the iaprefix and so on), and it saves on = implementations having to do all those checks. as an example of what we = would get into. what should an implementation do if it gets a exclude = prefix that isn't part of the ia_prefix? send a Decline option (which is = very specific to address assignment, and would have to be redefined). Strictly speaking, if the server sends a mask that doesn't work, that's = a configuration error. It's easily corrected by fixing the = configuration. There's no need for the client to do anything special, = because the configuration isn't going to work, and human intervention is = going to be required. Defining the extension in such a way that a = configuration error is impossible is certainly better than having to = deal with misconfiguration. However, I think SJ's concern is a valid = one.= From volz@cisco.com Fri May 13 11:36:19 2011 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 9ED3FE0853 for ; Fri, 13 May 2011 11:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.365 X-Spam-Level: X-Spam-Status: No, score=-10.365 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2rGmhEbcMAR for ; Fri, 13 May 2011 11:36:18 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id DE958E0851 for ; Fri, 13 May 2011 11:36:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=1744; q=dns/txt; s=iport; t=1305311778; x=1306521378; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=rZFWwhRA7odTV9bCYrx1kvW+wKKCyMvVkYBaC7J+CjI=; b=f+xwYQEe4+RCjB0y8WE6hJ3zMzSONiD6D6BpgM0wknpvO0CtFp3Sulen fAlfueEGp1u22QHv1gnH0bQDo2Inx6suiiYt/qh27eqv6bYoDAKfJc1Pp rWqZZGJKt0yGtl8RPA+nF6AozO0xMT6UyDSiZdP63N59VwqfOAbKjxf2j o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEBAHN5zU2tJV2Z/2dsb2JhbACXSY5Bd6d6ngGGFQSGTY1xilg X-IronPort-AV: E=Sophos;i="4.64,365,1301875200"; d="scan'208";a="356636359" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by sj-iport-2.cisco.com with ESMTP; 13 May 2011 18:36:18 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p4DIaI8k031146; Fri, 13 May 2011 18:36:18 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, 13 May 2011 13:36:17 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 13 May 2011 13:36:14 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] WG adoption of draft-asati-dhc-relay-agent-config-00 Thread-Index: AcwRmzuicyZXthW9RvCQETquo6QhuwAAGNrA References: <067E6CE33034954AAC05C9EC85E2577C04905E0E@XMB-RCD-111.cisco.com> <9105F293-1C25-4546-85B0-CF1E1A035CD9@nominum.com> From: "Bernie Volz (volz)" To: "Ted Lemon" , "Leaf yeh" X-OriginalArrivalTime: 13 May 2011 18:36:17.0821 (UTC) FILETIME=[A5A02CD0:01CC119C] Cc: dhcwg@ietf.org Subject: Re: [dhcwg] WG adoption of draft-asati-dhc-relay-agent-config-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, 13 May 2011 18:36:19 -0000 While I was only CC'd, I'm still not sure exactly what this is -- Is this the same as in Ralph's draft http://tools.ietf.org/id/draft-ietf-dhc-container-opt-05.txt (perhaps so as Ralph is co-author). If so, hasn't this already been approved as a DHC WG work item given that Ralph's now expired draft is a draft-ietf-dhc one? So, why would we need to revisit that part of the question? And, why isn't this new draft not just -06 of Ralph's old draft? - Bernie -----Original Message----- From: Ted Lemon [mailto:Ted.Lemon@nominum.com]=20 Sent: Friday, May 13, 2011 2:26 PM To: Leaf yeh Cc: dhcwg@ietf.org; Bernie Volz (volz) Subject: Re: [dhcwg] WG adoption of draft-asati-dhc-relay-agent-config-00 On May 12, 2011, at 4:07 AM, Leaf yeh wrote: > 1. Do we really need a new option with new structure or architecture for the relay configuration in the case of IPv4 & IPv6? > 2. Would the 2nd draft raise a reasonable solution for BGP/MPLS IP/VPN (RFC4364) per the section 1 & 3 of this draft (draft-asati)? I think the use case addressed by the draft does require some enabling extension. My suggestion was to put an ORO in the Relay-Forw message and have the server send back options that way, rather than defining a new container. Although having said that, I now feel the need to step back a pace. It doesn't actually make sense to piggyback this functionality on top of a DHCP client message. In any case, none of this is germane to the question of whether or not this is work the working group ought to do. Part of the work of the working group is figuring out the right solution to the problem. The question in the call for adoption is, do we think this is work that is worth doing? From akostur@incognito.com Fri May 13 12:19:51 2011 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 1D815E062A for ; Fri, 13 May 2011 12:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OcVQrTHHiO9N for ; Fri, 13 May 2011 12:19:50 -0700 (PDT) Received: from na3sys010aog104.obsmtp.com (na3sys010aog104.obsmtp.com [74.125.245.76]) by ietfa.amsl.com (Postfix) with SMTP id 3CE06E070C for ; Fri, 13 May 2011 12:19:49 -0700 (PDT) Received: from mail-vw0-f53.google.com ([209.85.212.53]) (using TLSv1) by na3sys010aob104.postini.com ([74.125.244.12]) with SMTP ID DSNKTc2EVfMxIheBfAzOVQEhrEIq6HcbXWid@postini.com; Fri, 13 May 2011 12:19:50 PDT Received: by vws13 with SMTP id 13so2559189vws.12 for ; Fri, 13 May 2011 12:19:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.116.42 with SMTP id jt10mr2571360vdb.36.1305314388146; Fri, 13 May 2011 12:19:48 -0700 (PDT) Received: by 10.52.188.232 with HTTP; Fri, 13 May 2011 12:19:48 -0700 (PDT) In-Reply-To: <62B5123D-3283-4F8B-A6CF-3BCEC6FE86C9@fugue.com> References: <99DF3B00-534F-4CA7-879B-8B64531C2513@nominum.com> <62B5123D-3283-4F8B-A6CF-3BCEC6FE86C9@fugue.com> Date: Fri, 13 May 2011 12:19:48 -0700 Message-ID: From: Andre Kostur To: Ted Lemon Content-Type: multipart/alternative; boundary=bcaec548a79f6cf84104a32d30c3 Cc: dhcwg@ietf.org, "Ralph Droms \(rdroms\)" , "Bernie Volz \(volz\)" , "Kim Kinnear \(kkinnear\)" Subject: Re: [dhcwg] FYI - A note regarding DHCPv6 from Interop 2011 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, 13 May 2011 19:19:51 -0000 --bcaec548a79f6cf84104a32d30c3 Content-Type: text/plain; charset=ISO-8859-1 Sorry.. I should have said "based on _a_ MAC address". Happens to be my current MAC address. DUID-LLT's were intentionally designed to survive the changing of a NIC (or multiple interfaces for that matter). On Fri, May 13, 2011 at 11:21, Ted Lemon wrote: > On May 11, 2011, at 7:46 PM, Andre Kostur wrote: > > At least on my Windows machine, the DUID is based on the MAC address. > DUID-LLT. > > > Yes, but it's based on the mac address of the machine at install time. If > you then clone the machine, the DUID-LLT will be cloned from the original, > so it won't contain the mac address of an interface on the clone. > > -- Andre Kostur Senior Software Design Engineer P: 604-678-2864 SIP: 864@incognito.com --bcaec548a79f6cf84104a32d30c3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Sorry.. I should have said "based on _a_ MAC address&= quot;. =A0Happens to be my current MAC address. =A0DUID-LLT's were inte= ntionally designed to survive the changing of a NIC (or multiple interfaces= for that matter).

On Fri, May 13, 2011 at 11:21, Ted Lemon <mellon@fugue.com= > wrote:
On May 11, = 2011, at 7:46 PM, Andre Kostur wrote:
At least on my Windows machine, the= DUID is based on the MAC address. =A0DUID-LLT.

Yes, but it's based on the mac addres= s of the machine at install time. =A0 If you then clone the machine, the DU= ID-LLT will be cloned from the original, so it won't contain the mac ad= dress of an interface on the clone.


--
Andre Kostur
Senior = Software Design Engineer
P: 604-678-2864 =A0SIP: 864@incognito.com

--bcaec548a79f6cf84104a32d30c3-- From rdroms.ietf@gmail.com Fri May 13 14:06:28 2011 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 D96E5E0886 for ; Fri, 13 May 2011 14:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.099 X-Spam-Level: X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UAZLIlKymfrl for ; Fri, 13 May 2011 14:06:27 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id BAB39E0885 for ; Fri, 13 May 2011 14:06:27 -0700 (PDT) Received: by yic13 with SMTP id 13so1163504yic.31 for ; Fri, 13 May 2011 14:06:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=nv5/yVeK8u/kLwGlgdRfi8htx4h7MUFw/RTUYrCppsg=; b=LzeqazZs56GFeGo5nhsJkstpH8JL5AqG2tgNzKQxjqx3puFqoperydmdKL3xF7b0XE fDQsvAz8CI0srD3oCsIqXo7l38+jms4oD7CEuSF1Dty5UacLd7WQmfCzuYNlvk9nZT06 CAk4ESXkXR5h2RZxr4xL4W0TQKBO3oEMeQgJU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=X+hqaMFUCHKdyf/6f/zKWkHOtHOaSwAvRtmqDCvtx0ugQvXomd0zEmPA6HQMri7EIo kqu9FhesdCIe0Rp6ZT8BFvy8iRsF3/JdJiTGTgW+AiKKPpVBgXNwQqhW6zvw5gPbcoWQ jYP6Htj47KM/jIu2dATcoYt64Y/vFeL4+ZB1s= Received: by 10.101.175.11 with SMTP id c11mr1253555anp.15.1305320786886; Fri, 13 May 2011 14:06:26 -0700 (PDT) Received: from [192.168.1.147] (c-24-62-225-5.hsd1.ma.comcast.net [24.62.225.5]) by mx.google.com with ESMTPS id v1sm1946079anh.51.2011.05.13.14.06.24 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 13 May 2011 14:06:25 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: Date: Fri, 13 May 2011 17:06:23 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9F50C95F-C2E3-4424-8DF9-3390FF7A23DB@gmail.com> References: <067E6CE33034954AAC05C9EC85E2577C04905E0E@XMB-RCD-111.cisco.com> <9105F293-1C25-4546-85B0-CF1E1A035CD9@nominum.com> To: "Bernie Volz (volz)" X-Mailer: Apple Mail (2.1082) Cc: dhcwg@ietf.org, Ralph Droms , Ted Lemon Subject: Re: [dhcwg] WG adoption of draft-asati-dhc-relay-agent-config-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, 13 May 2011 21:06:29 -0000 Bernie - this new draft has a different purpose altogether. = draft-ietf-dhc-container-opt-05 was intended for use between a client in = a router (e.g., a home router) and a server. The client in the router = would then hand those parameters to a DHCP server in the router for use = on other interfaces (e.g., the LAN interfaces on a home router). draft-asati-dhc-relay-agent-config provides a path for passing = configuration parameters from a server to a relay agent, which can't be = done today in the Router Information option because that option is = defined only to carry information from the relay agent to the server. - Ralph On May 13, 2011, at 2:36 PM 5/13/11, Bernie Volz (volz) wrote: > While I was only CC'd, I'm still not sure exactly what this is -- Is > this the same as in Ralph's draft > http://tools.ietf.org/id/draft-ietf-dhc-container-opt-05.txt (perhaps = so > as Ralph is co-author). >=20 > If so, hasn't this already been approved as a DHC WG work item given > that Ralph's now expired draft is a draft-ietf-dhc one? So, why would = we > need to revisit that part of the question? >=20 > And, why isn't this new draft not just -06 of Ralph's old draft? >=20 > - Bernie >=20 > -----Original Message----- > From: Ted Lemon [mailto:Ted.Lemon@nominum.com]=20 > Sent: Friday, May 13, 2011 2:26 PM > To: Leaf yeh > Cc: dhcwg@ietf.org; Bernie Volz (volz) > Subject: Re: [dhcwg] WG adoption of > draft-asati-dhc-relay-agent-config-00 >=20 > On May 12, 2011, at 4:07 AM, Leaf yeh wrote: >> 1. Do we really need a new option with new structure or architecture > for the relay configuration in the case of IPv4 & IPv6? >> 2. Would the 2nd draft raise a reasonable solution for BGP/MPLS > IP/VPN (RFC4364) per the section 1 & 3 of this draft (draft-asati)? >=20 > I think the use case addressed by the draft does require some enabling > extension. My suggestion was to put an ORO in the Relay-Forw message > and have the server send back options that way, rather than defining a > new container. >=20 > Although having said that, I now feel the need to step back a pace. = It > doesn't actually make sense to piggyback this functionality on top of = a > DHCP client message. >=20 > In any case, none of this is germane to the question of whether or not > this is work the working group ought to do. Part of the work of the > working group is figuring out the right solution to the problem. The > question in the call for adoption is, do we think this is work that is > worth doing? >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From volz@cisco.com Fri May 13 14:13:11 2011 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 5FA3DE0804 for ; Fri, 13 May 2011 14:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.399 X-Spam-Level: X-Spam-Status: No, score=-10.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4PTRze0cW1Qm for ; Fri, 13 May 2011 14:13:10 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id B57A3E078B for ; Fri, 13 May 2011 14:13:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=3209; q=dns/txt; s=iport; t=1305321190; x=1306530790; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=jQx+Iy7HbXOlOommB8JU82gynPc7YLIykHcGPETd5bk=; b=IqS1gB20kZqiYdS8kOqCPQDHYwvGEWtwsXj9AwEWYJbeD4cMsAzstBib 6GLpFQkUetQIJBWDK20ccb2vgyRUhWL0np35YJZ5Fvkw6smSrDaCAXP+o B0rB4Y3hhEwTmaQDRzykZEscaWF9wM1G4dcW28eDH3by9VU4AJ5e3eaTV M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEBAEqezU2tJXG8/2dsb2JhbACXTo5Bd4hwnkydfYYVBIZNjXGEE4ZF X-IronPort-AV: E=Sophos;i="4.64,366,1301875200"; d="scan'208";a="447504802" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by sj-iport-1.cisco.com with ESMTP; 13 May 2011 21:13:07 +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.3/8.14.3) with ESMTP id p4DLD7Dv021331; Fri, 13 May 2011 21:13:07 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, 13 May 2011 16:13:06 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 13 May 2011 16:13:00 -0500 Message-ID: In-Reply-To: <9F50C95F-C2E3-4424-8DF9-3390FF7A23DB@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] WG adoption of draft-asati-dhc-relay-agent-config-00 Thread-Index: AcwRsaL/oSaNkyWtSxq++YHI390cDgAAJSWA References: <067E6CE33034954AAC05C9EC85E2577C04905E0E@XMB-RCD-111.cisco.com> <9105F293-1C25-4546-85B0-CF1E1A035CD9@nominum.com> <9F50C95F-C2E3-4424-8DF9-3390FF7A23DB@gmail.com> From: "Bernie Volz (volz)" To: "Ralph Droms" X-OriginalArrivalTime: 13 May 2011 21:13:06.0539 (UTC) FILETIME=[8DA89BB0:01CC11B2] Cc: dhcwg@ietf.org, Ted Lemon Subject: Re: [dhcwg] WG adoption of draft-asati-dhc-relay-agent-config-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, 13 May 2011 21:13:11 -0000 Router usually =3D=3D Relay Agent?? I think this option is for DHCPv4? Is draft-ietf-dhc-container-opt-05 dead? If not, then perhaps there also needs to be some discussion regarding when it vs this new document are to be used? - Bernie -----Original Message----- From: Ralph Droms [mailto:rdroms.ietf@gmail.com]=20 Sent: Friday, May 13, 2011 5:06 PM To: Bernie Volz (volz) Cc: Ralph Droms; Ted Lemon; Leaf yeh; dhcwg@ietf.org Subject: Re: [dhcwg] WG adoption of draft-asati-dhc-relay-agent-config-00 Bernie - this new draft has a different purpose altogether. draft-ietf-dhc-container-opt-05 was intended for use between a client in a router (e.g., a home router) and a server. The client in the router would then hand those parameters to a DHCP server in the router for use on other interfaces (e.g., the LAN interfaces on a home router). draft-asati-dhc-relay-agent-config provides a path for passing configuration parameters from a server to a relay agent, which can't be done today in the Router Information option because that option is defined only to carry information from the relay agent to the server. - Ralph On May 13, 2011, at 2:36 PM 5/13/11, Bernie Volz (volz) wrote: > While I was only CC'd, I'm still not sure exactly what this is -- Is > this the same as in Ralph's draft > http://tools.ietf.org/id/draft-ietf-dhc-container-opt-05.txt (perhaps so > as Ralph is co-author). >=20 > If so, hasn't this already been approved as a DHC WG work item given > that Ralph's now expired draft is a draft-ietf-dhc one? So, why would we > need to revisit that part of the question? >=20 > And, why isn't this new draft not just -06 of Ralph's old draft? >=20 > - Bernie >=20 > -----Original Message----- > From: Ted Lemon [mailto:Ted.Lemon@nominum.com]=20 > Sent: Friday, May 13, 2011 2:26 PM > To: Leaf yeh > Cc: dhcwg@ietf.org; Bernie Volz (volz) > Subject: Re: [dhcwg] WG adoption of > draft-asati-dhc-relay-agent-config-00 >=20 > On May 12, 2011, at 4:07 AM, Leaf yeh wrote: >> 1. Do we really need a new option with new structure or architecture > for the relay configuration in the case of IPv4 & IPv6? >> 2. Would the 2nd draft raise a reasonable solution for BGP/MPLS > IP/VPN (RFC4364) per the section 1 & 3 of this draft (draft-asati)? >=20 > I think the use case addressed by the draft does require some enabling > extension. My suggestion was to put an ORO in the Relay-Forw message > and have the server send back options that way, rather than defining a > new container. >=20 > Although having said that, I now feel the need to step back a pace. It > doesn't actually make sense to piggyback this functionality on top of a > DHCP client message. >=20 > In any case, none of this is germane to the question of whether or not > this is work the working group ought to do. Part of the work of the > working group is figuring out the right solution to the problem. The > question in the call for adoption is, do we think this is work that is > worth doing? >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From rdroms.ietf@gmail.com Fri May 13 14:17:09 2011 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 DC5F7E089C for ; Fri, 13 May 2011 14:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qxw+3aBUWs1g for ; Fri, 13 May 2011 14:17:09 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id 42FFCE089B for ; Fri, 13 May 2011 14:17:09 -0700 (PDT) Received: by pvh18 with SMTP id 18so642629pvh.31 for ; Fri, 13 May 2011 14:17:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=D8kNbyh2oOcue+OL40PKgg8uhm3F2depugXbvOMhTWM=; b=cowyOienMBJlZl547Xmx2XnwyGCzzFwT+g6rGgu61CGFJVkLeWt3q8kL0rvP4sIjMt p2eFaL61kYjvJtNM9PY7KiEDlRZ3gN+90rFVSRh1EFS3+BG8z7qymhM+/w1xXM/vJ9q8 2FiEZ1L9JNnf4gW597MCcLhuqnhalhAb8L5UA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=evJc+boFgXtbLts34C/fnQwkQIdt+Q7gUSOdLvlMr8rcPOCPFlOqzh8G0ug/Oz7iJV 1pI5YBb8aQgRKb17hYBXJ8hO8cDlwsWFwSIi+Ofj/Avjhaxmgm+3kfylO2gVoyySbb/K 1m3XiuVWffCPCNfd8uvzPe4cZcKcKhy+1Vhg0= Received: by 10.142.9.28 with SMTP id 28mr1179418wfi.399.1305321428935; Fri, 13 May 2011 14:17:08 -0700 (PDT) Received: from sjc-vpnasa-915.cisco.com (128-107-239-233.cisco.com [128.107.239.233]) by mx.google.com with ESMTPS id w14sm2398566wfh.8.2011.05.13.14.17.06 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 13 May 2011 14:17:08 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: Date: Fri, 13 May 2011 17:17:03 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3E37B819-E1DB-4D99-99E0-9FD5C4603AF8@gmail.com> References: <067E6CE33034954AAC05C9EC85E2577C04905E0E@XMB-RCD-111.cisco.com> <9105F293-1C25-4546-85B0-CF1E1A035CD9@nominum.com> <9F50C95F-C2E3-4424-8DF9-3390FF7A23DB@gmail.com> To: "Bernie Volz (volz)" X-Mailer: Apple Mail (2.1082) Cc: dhcwg@ietf.org, Ralph Droms , Ted Lemon Subject: Re: [dhcwg] WG adoption of draft-asati-dhc-relay-agent-config-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, 13 May 2011 21:17:10 -0000 In the case of draft-ietf-dhc-container-opt-05 and talking about a home = router, it's the client in the router on the WAN interface passing = information to the server in the router on the LAN interface. No relay = agent involved. I haven't heard any interest from ISPs (the primary customer) in = draft-ietf-dhc-container-opt-05, so "it's dead, Jim". - Ralph, who is a protocol engineer, not a doctor On May 13, 2011, at 5:13 PM 5/13/11, Bernie Volz (volz) wrote: > Router usually =3D=3D Relay Agent?? I think this option is for DHCPv4? >=20 > Is draft-ietf-dhc-container-opt-05 dead? If not, then perhaps there = also > needs to be some discussion regarding when it vs this new document are > to be used? >=20 > - Bernie >=20 > -----Original Message----- > From: Ralph Droms [mailto:rdroms.ietf@gmail.com]=20 > Sent: Friday, May 13, 2011 5:06 PM > To: Bernie Volz (volz) > Cc: Ralph Droms; Ted Lemon; Leaf yeh; dhcwg@ietf.org > Subject: Re: [dhcwg] WG adoption of > draft-asati-dhc-relay-agent-config-00 >=20 > Bernie - this new draft has a different purpose altogether. > draft-ietf-dhc-container-opt-05 was intended for use between a client = in > a router (e.g., a home router) and a server. The client in the router > would then hand those parameters to a DHCP server in the router for = use > on other interfaces (e.g., the LAN interfaces on a home router). >=20 > draft-asati-dhc-relay-agent-config provides a path for passing > configuration parameters from a server to a relay agent, which can't = be > done today in the Router Information option because that option is > defined only to carry information from the relay agent to the server. >=20 > - Ralph >=20 > On May 13, 2011, at 2:36 PM 5/13/11, Bernie Volz (volz) wrote: >=20 >> While I was only CC'd, I'm still not sure exactly what this is -- Is >> this the same as in Ralph's draft >> http://tools.ietf.org/id/draft-ietf-dhc-container-opt-05.txt (perhaps > so >> as Ralph is co-author). >>=20 >> If so, hasn't this already been approved as a DHC WG work item given >> that Ralph's now expired draft is a draft-ietf-dhc one? So, why would > we >> need to revisit that part of the question? >>=20 >> And, why isn't this new draft not just -06 of Ralph's old draft? >>=20 >> - Bernie >>=20 >> -----Original Message----- >> From: Ted Lemon [mailto:Ted.Lemon@nominum.com]=20 >> Sent: Friday, May 13, 2011 2:26 PM >> To: Leaf yeh >> Cc: dhcwg@ietf.org; Bernie Volz (volz) >> Subject: Re: [dhcwg] WG adoption of >> draft-asati-dhc-relay-agent-config-00 >>=20 >> On May 12, 2011, at 4:07 AM, Leaf yeh wrote: >>> 1. Do we really need a new option with new structure or = architecture >> for the relay configuration in the case of IPv4 & IPv6? >>> 2. Would the 2nd draft raise a reasonable solution for BGP/MPLS >> IP/VPN (RFC4364) per the section 1 & 3 of this draft (draft-asati)? >>=20 >> I think the use case addressed by the draft does require some = enabling >> extension. My suggestion was to put an ORO in the Relay-Forw = message >> and have the server send back options that way, rather than defining = a >> new container. >>=20 >> Although having said that, I now feel the need to step back a pace. > It >> doesn't actually make sense to piggyback this functionality on top of > a >> DHCP client message. >>=20 >> In any case, none of this is germane to the question of whether or = not >> this is work the working group ought to do. Part of the work of the >> working group is figuring out the right solution to the problem. = The >> question in the call for adoption is, do we think this is work that = is >> worth doing? >>=20 >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg >=20 From Ted.Lemon@nominum.com Fri May 13 19:07:25 2011 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 1B843E07C3 for ; Fri, 13 May 2011 19:07:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.399 X-Spam-Level: X-Spam-Status: No, score=-106.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FXEq2-DyYyRO for ; Fri, 13 May 2011 19:07:24 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by ietfa.amsl.com (Postfix) with ESMTP id D35E8E07AB for ; Fri, 13 May 2011 19:07:23 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKTc3j24X4nt6iotqazYvCKKNNaCy0KNFg@postini.com; Fri, 13 May 2011 19:07:23 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 BFFFC1B85E6 for ; Fri, 13 May 2011 19:07:22 -0700 (PDT) Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id AED4E190052; Fri, 13 May 2011 19:07:22 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from vpna-148.vpn.nominum.com (64.89.227.148) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 13 May 2011 19:07:22 -0700 MIME-Version: 1.0 (Apple Message framework v1222) Content-Type: text/plain; charset="us-ascii" From: Ted Lemon In-Reply-To: Date: Fri, 13 May 2011 22:07:15 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <3A2F4BD1-C3C0-4C5A-827E-F25120525852@nominum.com> References: <067E6CE33034954AAC05C9EC85E2577C04905E0E@XMB-RCD-111.cisco.com> <9105F293-1C25-4546-85B0-CF1E1A035CD9@nominum.com> To: Bernie Volz X-Mailer: Apple Mail (2.1222) Cc: dhcwg@ietf.org Subject: Re: [dhcwg] WG adoption of draft-asati-dhc-relay-agent-config-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: Sat, 14 May 2011 02:07:25 -0000 On May 13, 2011, at 2:36 PM, Bernie Volz (volz) wrote: > While I was only CC'd, I'm still not sure exactly what this is -- Is > this the same as in Ralph's draft > http://tools.ietf.org/id/draft-ietf-dhc-container-opt-05.txt (perhaps = so > as Ralph is co-author). No, it's to configure the relay agent, not to configure what the relay = agent sends to the client. Or so I understand it. From Internet-Drafts@ietf.org Sun May 15 20:00:02 2011 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 C3312E06B9; Sun, 15 May 2011 20:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.548 X-Spam-Level: X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W97BGZXZBq+U; Sun, 15 May 2011 20:00:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A945E06D9; Sun, 15 May 2011 20:00:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.54 Message-ID: <20110516030002.20926.6271.idtracker@ietfa.amsl.com> Date: Sun, 15 May 2011 20:00:02 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action:draft-ietf-dhc-host-gen-id-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, 16 May 2011 03:00:02 -0000 --NextPart 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. Title : Prefix Assignment in DHCPv6 Author(s) : S. Jiang, et al. Filename : draft-ietf-dhc-host-gen-id-00.txt Pages : 10 Date : 2011-05-15 This document describes 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-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dhc-host-gen-id-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-05-15195348.I-D@ietf.org> --NextPart-- From ichiroumakino@gmail.com Mon May 16 01:39:56 2011 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 A3441E0749 for ; Mon, 16 May 2011 01:39:56 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6RsCeSpbPiIa for ; Mon, 16 May 2011 01:39:56 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id ED96CE070B for ; Mon, 16 May 2011 01:39:55 -0700 (PDT) Received: by wyb29 with SMTP id 29so3798583wyb.31 for ; Mon, 16 May 2011 01:39:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=qW87XyhWNrzp4PBysxymnF9AXxaV4CTRQyldtMdjr74=; b=I8logoBPd4vDXLuDaCXTBrZZWYakJBJMXOaKRVOHEX0gBVF1nOtAyx9IGx7Cej8Gcm pHhbJ7rYila3U11jA64DSuBJrCDeA8ixekOHFr0WV7EQujw0Qt/V6FSJYqx5nPtx1ZDl PMCckE6SRjRzYRm+Us2l5VW+tFBNyzyGwmE4s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=Duxz/cdBDkq1RQTr892dmQIqRD4KoQlLovUwmnL8LMuXjsNkVZbiC5xMEXw1YZfeVz bAQ+H5vGLSGzZE/IVpGDgOLVx7L55fX4ZB6mi5PcXnV/jLrLDgyVxNinOq4MoQdoE1Hu O5Hjs5WDf+58a8au4zVy+aGDghhdp9NimcmqY= Received: by 10.227.59.210 with SMTP id m18mr3974148wbh.112.1305535194378; Mon, 16 May 2011 01:39:54 -0700 (PDT) Received: from dhcp-osl-vl300-64-103-53-110.cisco.com (dhcp-osl-vl300-64-103-53-110.cisco.com [64.103.53.110]) by mx.google.com with ESMTPS id l24sm2989895wbc.47.2011.05.16.01.39.50 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 16 May 2011 01:39:51 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: Date: Mon, 16 May 2011 10:39:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0A9E5618-8044-40BA-AC6B-225290B40F09@employees.org> References: To: Ted Lemon X-Mailer: Apple Mail (2.1084) Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] Call for adoption: draft-guo-softwire-6rd-ipv6-config-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: Mon, 16 May 2011 08:39:56 -0000 > This document proposes a mechanism for configuring the IPv6 stack over = a 6RD tunnel using DHCPv6. It was presented at the meeting in Prague. = This is an interesting problem because the DHCPv6 spec prevents DHCP = clients from configuring themselves directly over tunnels. Two solutions = were suggested: either relax some restrictions in RFC3315 with regard to = source addresses, or else use a DHCPv6 relay agent to forward the packet = over the tunnel. The consensus of the room was to adopt the work; = although this is related to 6RD, it is a DHCP-specific draft, so there = was agreement that the DHC working group is the right place for the = work. >=20 > If you agree that the working group should do this work, please = indicate that agreement on the list; likewise if you disagree. If you = have no opinion, there is no need to say so. agree. (and think this has wider applicability than just 6rd (basically = any link that doesn't support link-local addressing or multicast or the = DHCPv6 client has a need to send directly to a server not directly = connected to it)). cheers, Ole From xuxh@huawei.com Mon May 16 02:30:29 2011 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 93630E0739 for ; Mon, 16 May 2011 02:30:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.51 X-Spam-Level: X-Spam-Status: No, score=-3.51 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kqbmuIOYUd1T for ; Mon, 16 May 2011 02:30:28 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 45FBFE06BD for ; Mon, 16 May 2011 02:30:28 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLA00LXV7NUBE@szxga03-in.huawei.com> for dhcwg@ietf.org; Mon, 16 May 2011 17:28:42 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLA0018V7NU05@szxga03-in.huawei.com> for dhcwg@ietf.org; Mon, 16 May 2011 17:28:42 +0800 (CST) Received: from x41208c ([10.110.98.38]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LLA000QU7NTNM@szxml04-in.huawei.com> for dhcwg@ietf.org; Mon, 16 May 2011 17:28:42 +0800 (CST) Date: Mon, 16 May 2011 17:38:04 +0800 From: Xu Xiaohu In-reply-to: <0A9E5618-8044-40BA-AC6B-225290B40F09@employees.org> To: 'Ole Troan' , 'Ted Lemon' Message-id: <002301cc13ac$f4e89e50$deb9daf0$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=gb2312 Content-language: zh-cn Content-transfer-encoding: quoted-printable Thread-index: AcwTpw8O9wjnLqJFQCeVV6b6Ls0hHwABbvLA References: <0A9E5618-8044-40BA-AC6B-225290B40F09@employees.org> Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Call for adoption: draft-guo-softwire-6rd-ipv6-config-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: Mon, 16 May 2011 09:30:29 -0000 I also agree that the working group should do this work. Best wishes, Xiaohu > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: dhcwg-bounces@ietf.org = [mailto:dhcwg-bounces@ietf.org] =B4=FA=B1=ED Ole > Troan > =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA5=D4=C216=C8=D5 16:40 > =CA=D5=BC=FE=C8=CB: Ted Lemon > =B3=AD=CB=CD: dhcwg@ietf.org WG > =D6=F7=CC=E2: Re: [dhcwg] Call for adoption: draft-guo-softwire-6rd-ipv6-config-02.txt >=20 > > This document proposes a mechanism for configuring the IPv6 stack = over a > 6RD tunnel using DHCPv6. It was presented at the meeting in Prague. > This is an interesting problem because the DHCPv6 spec prevents DHCP clients > from configuring themselves directly over tunnels. Two solutions were > suggested: either relax some restrictions in RFC3315 with regard to = source > addresses, or else use a DHCPv6 relay agent to forward the packet over = the > tunnel. The consensus of the room was to adopt the work; although = this is > related to 6RD, it is a DHCP-specific draft, so there was agreement = that the > DHC working group is the right place for the work. > > > > If you agree that the working group should do this work, please = indicate that > agreement on the list; likewise if you disagree. If you have no = opinion, there > is no need to say so. >=20 > agree. (and think this has wider applicability than just 6rd = (basically any link > that doesn't support link-local addressing or multicast or the DHCPv6 client has > a need to send directly to a server not directly connected to it)). >=20 > cheers, > Ole >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From mark@townsley.net Mon May 16 02:32:12 2011 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 A3D04E070B for ; Mon, 16 May 2011 02:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.81 X-Spam-Level: X-Spam-Status: No, score=-0.81 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j2C32GOBTrUz for ; Mon, 16 May 2011 02:32:12 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id B549DE065D for ; Mon, 16 May 2011 02:32:11 -0700 (PDT) Received: by wwa36 with SMTP id 36so3318524wwa.13 for ; Mon, 16 May 2011 02:32:10 -0700 (PDT) Received: by 10.227.57.78 with SMTP id b14mr4077284wbh.106.1305538330685; Mon, 16 May 2011 02:32:10 -0700 (PDT) Received: from ams-townsley-8714.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id b20sm3017261wbb.67.2011.05.16.02.32.07 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 16 May 2011 02:32:08 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=GB2312 From: Mark Townsley In-Reply-To: <002301cc13ac$f4e89e50$deb9daf0$@com> Date: Mon, 16 May 2011 11:32:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <49410246-B6B2-4BC6-990A-B668D775DF98@townsley.net> References: <0A9E5618-8044-40BA-AC6B-225290B40F09@employees.org> <002301cc13ac$f4e89e50$deb9daf0$@com> To: Xu Xiaohu X-Mailer: Apple Mail (2.1084) Cc: dhcwg@ietf.org, 'Ted Lemon' Subject: Re: [dhcwg] Call for adoption: draft-guo-softwire-6rd-ipv6-config-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: Mon, 16 May 2011 09:32:12 -0000 +1 On May 16, 2011, at 11:38 AM, Xu Xiaohu wrote: > I also agree that the working group should do this work. >=20 > Best wishes, > Xiaohu >=20 >> -----=D3=CA=BC=FE=D4=AD=BC=FE----- >> =B7=A2=BC=FE=C8=CB: dhcwg-bounces@ietf.org = [mailto:dhcwg-bounces@ietf.org] =B4=FA=B1=ED Ole >> Troan >> =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA5=D4=C216=C8=D5 16:40 >> =CA=D5=BC=FE=C8=CB: Ted Lemon >> =B3=AD=CB=CD: dhcwg@ietf.org WG >> =D6=F7=CC=E2: Re: [dhcwg] Call for adoption: > draft-guo-softwire-6rd-ipv6-config-02.txt >>=20 >>> This document proposes a mechanism for configuring the IPv6 stack = over a >> 6RD tunnel using DHCPv6. It was presented at the meeting in Prague. >> This is an interesting problem because the DHCPv6 spec prevents DHCP > clients >> from configuring themselves directly over tunnels. Two solutions were >> suggested: either relax some restrictions in RFC3315 with regard to = source >> addresses, or else use a DHCPv6 relay agent to forward the packet = over the >> tunnel. The consensus of the room was to adopt the work; although = this > is >> related to 6RD, it is a DHCP-specific draft, so there was agreement = that > the >> DHC working group is the right place for the work. >>>=20 >>> If you agree that the working group should do this work, please = indicate > that >> agreement on the list; likewise if you disagree. If you have no = opinion, > there >> is no need to say so. >>=20 >> agree. (and think this has wider applicability than just 6rd = (basically > any link >> that doesn't support link-local addressing or multicast or the DHCPv6 > client has >> a need to send directly to a server not directly connected to it)). >>=20 >> cheers, >> Ole >>=20 >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From ichiroumakino@gmail.com Mon May 16 04:10:01 2011 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 BD77BE076D for ; Mon, 16 May 2011 04:10: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QPAlZLazYtUX for ; Mon, 16 May 2011 04:09:51 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5E720E0722 for ; Mon, 16 May 2011 04:09:51 -0700 (PDT) Received: by wwa36 with SMTP id 36so3381699wwa.13 for ; Mon, 16 May 2011 04:09:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=v7p3Mn+U/Ao7LW3Ltb0D2jeez2QLisMlH4EesSWBk0Q=; b=wWL9/I8zKt4DJtxK9MqQFTlPJrDTcrCI4yd0XzT8gSjGxr2alIH3tZAr6C0o8X5iUF 7/CTE59q11lKHq2qr/0Z1mxJgg3yNFWgnL5cO5KjsjvSzrJqksZPETEtEHVKjkqfikX2 PlSfpKwLS6cBbgp+OvJcvb6w/8KAO8MhUHlNE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=J/fdw4TEfpLpOIuk2FRV9YNGO1vQURAhjF0WQlv6TqsM/zuSkEy1s9ahYBsM9HwpLf eNrJTrUpeDJ3tmF6QPiWkLJuKZPo4CeWZg6wBHXXS2Z0TgatATZl3+DOBXbSDTB2e36b QZJuAsWEqiwp7eRAuYKOjbfNcSxUUDvCUlj+o= Received: by 10.216.237.67 with SMTP id x45mr2087665weq.72.1305544190433; Mon, 16 May 2011 04:09:50 -0700 (PDT) Received: from dhcp-osl-vl300-64-103-53-110.cisco.com (dhcp-osl-vl300-64-103-53-110.cisco.com [64.103.53.110]) by mx.google.com with ESMTPS id y29sm3073498wbd.4.2011.05.16.04.09.47 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 16 May 2011 04:09:47 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: Date: Mon, 16 May 2011 13:09:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1836BEF9-0739-4783-9A49-15F01D645F5D@employees.org> References: <94200415-3C9D-4C61-88AB-42A6D0E11649@nominum.com> <4DC864D1.8010101@gmail.com> <20110511184158.GB4138@shell-too.nominum.com> <68614430-1044-45EE-9B64-354284B13D87@gmail.com> To: Ted Lemon X-Mailer: Apple Mail (2.1084) Cc: dhcwg@ietf.org Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-pd-exclude-01 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, 16 May 2011 11:10:01 -0000 >> I think the current coding is very elegant. I don't care so much = about saving the few bytes. but avoiding having redundant information in = the option saves on both lots of text describing the corner cases (e.g. = the exclude isn't part of the iaprefix and so on), and it saves on = implementations having to do all those checks. as an example of what we = would get into. what should an implementation do if it gets a exclude = prefix that isn't part of the ia_prefix? send a Decline option (which is = very specific to address assignment, and would have to be redefined). >=20 > Strictly speaking, if the server sends a mask that doesn't work, = that's a configuration error. It's easily corrected by fixing the = configuration. There's no need for the client to do anything special, = because the configuration isn't going to work, and human intervention is = going to be required. Defining the extension in such a way that a = configuration error is impossible is certainly better than having to = deal with misconfiguration. However, I think SJ's concern is a valid = one. the idea behind the option was to encode it like: ia_prefix option: 2001:db8::/48 exclude subnet option: 0001 /64 giving the complete excluded prefix: 2001:db8 + 0001 =3D> = 2001:db8:0001::/64 the alternative would be: ia_prefix option: 2001:db8::/48 exclude subnet option: 2001:db8:0001::/64 at least a check that the excluded prefix is a subnet of prefix has to = be done in this case. I do agree with SJ's concern though, we apparently haven't been able to = describe the what I thought of as a simple concatenation very well. can we do another try at better text for the current encoding, or does = the working group prefer the explicit coding in option 2? cheers, Ole From leaf.y.yeh@huawei.com Mon May 16 04:12:39 2011 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 99BD1E070E for ; Mon, 16 May 2011 04:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.266 X-Spam-Level: X-Spam-Status: No, score=-5.266 tagged_above=-999 required=5 tests=[AWL=1.333, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B1AuofhQl0Np for ; Mon, 16 May 2011 04:12:38 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id A13CFE06BF for ; Mon, 16 May 2011 04:12:38 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLA00KS8CDVRC@szxga03-in.huawei.com> for dhcwg@ietf.org; Mon, 16 May 2011 19:10:43 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLA00D1VCDVNN@szxga03-in.huawei.com> for dhcwg@ietf.org; Mon, 16 May 2011 19:10:43 +0800 (CST) Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 16 May 2011 19:10:41 +0800 Received: from SZXEML514-MBX.china.huawei.com ([169.254.2.14]) by szxeml403-hub.china.huawei.com ([169.254.173.75]) with mapi id 14.01.0270.001; Mon, 16 May 2011 19:10:42 +0800 Date: Mon, 16 May 2011 11:10:40 +0000 From: Leaf yeh In-reply-to: X-Originating-IP: [10.70.39.133] To: Ted Lemon Message-id: MIME-version: 1.0 Content-type: text/plain; charset=Windows-1252 Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: [dhcwg] WG adoption of draft-asati-dhc-relay-agent-config-00 Thread-index: AcvwvmvXzCHd+ukFSkSNyX8FCnzm+gYI7ONAAZfrWYAAEvCUcAABKYoAACyfDpAARN1xAACHr5XQ X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <067E6CE33034954AAC05C9EC85E2577C04905E0E@XMB-RCD-111.cisco.com> <9105F293-1C25-4546-85B0-CF1E1A035CD9@nominum.com> Cc: "dhcwg@ietf.org" , "Bernie Volz \(volz\)" , "rdroms.ietf@gmail.com" Subject: Re: [dhcwg] WG adoption of draft-asati-dhc-relay-agent-config-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: Mon, 16 May 2011 11:12:39 -0000 Ted - My suggestion was to put an ORO in the Relay-Forw message and have the server send back options that way, rather than defining a new container. Although having said that, I now feel the need to step back a pace. It doesn't actually make sense to piggyback this functionality on top of a DHCP client message. 2 more question on the draft-asati: a. Not quite sure this draft will cover DHCPv6 per the format of the new proposed option in Section 4 and the description on behavior of Relay in Section 5; b. Supposed the new option proposed in this draft does piggyback on top of a DHCP client message per the description on behavior of Relay in Section 5, right? Best Regards, Leaf PS. draft-asati-dhc-relay-agent-config-00 Section 5.1 The relay agent adds the DHCP relay agent configuration option (& needed sub-options) in the relayed message to request the relay agent side configuration information from the server...A relay agent adding a Relay Agent Configuration Information Option MUST add it as the last option (but before 'End Option' 255, if present) or the second last option, if option 82 is present, in the DHCP options field of any recognized BOOTP or DHCP packet forwarded from a client to a server...The relay agent MUST remove the relay agent configuration option from the DHCP response and forward the remaining response to the client. Section 5.3 ... The new option defined in this document is never passed to the client... -----Original Message----- From: Ted Lemon [mailto:Ted.Lemon@nominum.com] Sent: Saturday, May 14, 2011 2:26 AM To: Leaf yeh Cc: dhcwg@ietf.org; Bernie Volz Subject: Re: [dhcwg] WG adoption of draft-asati-dhc-relay-agent-config-00 On May 12, 2011, at 4:07 AM, Leaf yeh wrote: > 1. Do we really need a new option with new structure or architecture for the relay configuration in the case of IPv4 & IPv6? > 2. Would the 2nd draft raise a reasonable solution for BGP/MPLS IP/VPN (RFC4364) per the section 1 & 3 of this draft (draft-asati)? I think the use case addressed by the draft does require some enabling extension. My suggestion was to put an ORO in the Relay-Forw message and have the server send back options that way, rather than defining a new container. Although having said that, I now feel the need to step back a pace. It doesn't actually make sense to piggyback this functionality on top of a DHCP client message. In any case, none of this is germane to the question of whether or not this is work the working group ought to do. Part of the work of the working group is figuring out the right solution to the problem. The question in the call for adoption is, do we think this is work that is worth doing? From jouni.nospam@gmail.com Mon May 16 04:59:55 2011 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 E6004E076D for ; Mon, 16 May 2011 04:59:55 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RFatLufrzgSW for ; Mon, 16 May 2011 04:59:55 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id D489BE06BD for ; Mon, 16 May 2011 04:59:54 -0700 (PDT) Received: by ewy19 with SMTP id 19so1591813ewy.31 for ; Mon, 16 May 2011 04:59:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=Cld0jEVHZGjYFA/7BsH2JqU3jg1NJKxTEAmsh6kZvZg=; b=Z8mOwnAGiGWY3ospAtwZJlx9VR7etFpnTPxxAGW8MsDx5vHolTzZqm/UJ+O+0Zt0mt AtxKEbQkd7f538nbh2HXXmBQgnIySYgrwtfA4yCQhBQDZl5z/q79bXVtVs0xUo1WwfYM d5sMnSJTuYVYEG5ieCSmKf3D867Qd4y2apP2g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=RbpiglxmcFvaEuIh4gzkbKYEI7zBTebk/uTMoTVlHCOzYyAr2hypN5PdSBjdKLBNO9 KcKtRJJvOyLt6QsFT1wHnLZx/1i6s9lnUEtNBLTHiVMozLiBWcr7FWV7VMYUZWrSRq5S nzBhMeNWCn+uJGs2lA5oNmmNV5kbRpJkHes58= Received: by 10.213.34.74 with SMTP id k10mr778649ebd.98.1305547193876; Mon, 16 May 2011 04:59:53 -0700 (PDT) Received: from a88-112-140-187.elisa-laajakaista.fi (a88-112-140-187.elisa-laajakaista.fi [88.112.140.187]) by mx.google.com with ESMTPS id y18sm3396392eeh.24.2011.05.16.04.59.51 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 16 May 2011 04:59:52 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <20110512192545.GA16742@shell-too.nominum.com> Date: Mon, 16 May 2011 14:59:49 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <484E738D-06CC-45F3-BB5C-4447AA907E64@gmail.com> References: <94200415-3C9D-4C61-88AB-42A6D0E11649@nominum.com> <4DC864D1.8010101@gmail.com> <20110511184158.GB4138@shell-too.nominum.com> <68614430-1044-45EE-9B64-354284B13D87@gmail.com> <20110512181249.GA12824@shell-too.nominum.com> <20110512192545.GA16742@shell-too.nominum.com> To: Stephen Jacob X-Mailer: Apple Mail (2.1082) Cc: dhcwg@ietf.org Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-pd-exclude-01 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, 16 May 2011 11:59:56 -0000 Hi, On May 12, 2011, at 10:25 PM, Stephen Jacob wrote: > On Thu, May 12, 2011 at 10:17:15PM +0300, jouni korhonen wrote: >> Stephen, >>=20 >>> I may have misunderstood. I interpreted it as saying (in the bit = about >>> octet-alignment) that if you had: >>> Prefix: abcd:ff00::/24 >>> Exclude prefix: abcd:ff11::/16 >>=20 >> You cannot exclude a shorter prefix than you delegate. Based on the >> above example you would actually be excluding abcd:ff11::/32. That >> would result to a subnet-id 0x11 and consume one octet. >=20 > Oops! I meant /32. Typo. I still see no other issue here except maybe my not too clear text how = the subnet-id gets extracted. The text can always be made clearer, = though. - Jouni >=20 > Regards, > Stephen > --=20 > Stephen Jacob | Stephen.Jacob@nominum.com | +1 650 381 6051 > Nominum, Inc. | http://www.nominum.com/ | +1 650 381 6000 From m.aleem-chisti@hp.com Tue May 17 03:09:03 2011 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 0CE60E070B for ; Tue, 17 May 2011 03:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O+8LAG4yEqDC for ; Tue, 17 May 2011 03:09:02 -0700 (PDT) Received: from g4t0015.houston.hp.com (g4t0015.houston.hp.com [15.201.24.18]) by ietfa.amsl.com (Postfix) with ESMTP id 0F436E0658 for ; Tue, 17 May 2011 03:09:01 -0700 (PDT) Received: from G5W0603.americas.hpqcorp.net (g5w0603.americas.hpqcorp.net [16.228.9.186]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g4t0015.houston.hp.com (Postfix) with ESMTPS id 4BDED8727 for ; Tue, 17 May 2011 10:09:01 +0000 (UTC) Received: from G1W1916.americas.hpqcorp.net (16.236.60.246) by G5W0603.americas.hpqcorp.net (16.228.9.186) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 17 May 2011 10:08:01 +0000 Received: from GVW1352EXA.americas.hpqcorp.net ([16.238.8.126]) by G1W1916.americas.hpqcorp.net ([16.236.60.246]) with mapi; Tue, 17 May 2011 10:08:00 +0000 From: "M A, Aleem Chisti" To: "dhcwg@ietf.org" Date: Tue, 17 May 2011 10:07:57 +0000 Thread-Topic: DHCPv6 RFC 3315 Clarification - T1 and T2 timer values in IA_NA option Thread-Index: AcwUekh/WOvdqVthSlmV1sK6gjYvlA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_BCCD681151F89347B4D7C5FE64A651D32E04A74429GVW1352EXAame_" MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 17 May 2011 03:33:48 -0700 Subject: [dhcwg] DHCPv6 RFC 3315 Clarification - T1 and T2 timer values in IA_NA option 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, 17 May 2011 10:15:21 -0000 --_000_BCCD681151F89347B4D7C5FE64A651D32E04A74429GVW1352EXAame_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Sec 22.4 of RFC 3315 describes the following on T1, T2 timer values: "If a client receives an IA_NA with T1 greater than T2, and both T1 and T2 are greater than 0, the client discards the IA_NA option and processes the remainder of the message as though the server had not included the invalid IA_NA option." However, this RFC doesn't mention about, what should be the client behavior= when T1 is equal to T2. How should the client deal in such a scenario ? Thanks Aleem --_000_BCCD681151F89347B4D7C5FE64A651D32E04A74429GVW1352EXAame_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Sec 22.4 of RFC 3315 describes the following on T1, = T2 timer values:

 

  “If a client receives an IA_NA with T1 = greater than T2, and both T1

   and T2 are greater than 0, the client d= iscards the IA_NA option and

   processes the remainder of the message = as though the server had not

   included the invalid IA_NA option.̶= 1;

 

However, this RFC doesn’t mention about, what = should be the client behavior when T1 is equal to T2.

 

How should the client deal in such a scenario ?=

 

Thanks

Aleem

 

 

--_000_BCCD681151F89347B4D7C5FE64A651D32E04A74429GVW1352EXAame_-- From budmillwood@gmail.com Tue May 17 05:14:04 2011 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 8AB1CE0743 for ; Tue, 17 May 2011 05:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iu0QpVTcRoPn for ; Tue, 17 May 2011 05:14:03 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9E425E0715 for ; Tue, 17 May 2011 05:14:03 -0700 (PDT) Received: by vxg33 with SMTP id 33so331406vxg.31 for ; Tue, 17 May 2011 05:14:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=VzaqJSdUqhfBo+E0SBl4QT60i5Qpld0k4aaeJjadAyg=; b=TdOuGapd054XirQmfeqWgHzgs04gwUCmU5orDmg5BJMux3JZvNcrX5Yh7ixbiocCL5 V8rIeQ2tNiCNPNfKZvF5OVAUk3rwKlg88nM2iHFJAn3olk47E/83F4QDBlXvjyuHWskv jfoAIfaFBLzm8Y3jbTTSg5WVuUImAeWORYimk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=EOEqP2pEVR+7tEUZXEnas1ctkYj42TtOABqCRVnmyVJ8uZorsQhf+kukXhzLTjTb4f xfrSVNhWLZcd5BZONQWVtpN9wDlrNQiOq9c+LiQUpXSG5uUAaffjWiJhqq6XrtgTo+Aq CR+VK0bGqUJ2qeJqtYPIlp/XQNEm4uUxCbLTI= MIME-Version: 1.0 Received: by 10.52.114.196 with SMTP id ji4mr761198vdb.29.1305634442757; Tue, 17 May 2011 05:14:02 -0700 (PDT) Received: by 10.52.113.101 with HTTP; Tue, 17 May 2011 05:14:02 -0700 (PDT) In-Reply-To: References: <99DF3B00-534F-4CA7-879B-8B64531C2513@nominum.com> Date: Tue, 17 May 2011 14:14:02 +0200 Message-ID: From: Bud Millwood To: "Bernie Volz (volz)" Content-Type: multipart/alternative; boundary=bcaec548a5032ac57904a377b592 Cc: dhcwg@ietf.org, "Ralph Droms \(rdroms\)" , "Kim Kinnear \(kkinnear\)" Subject: Re: [dhcwg] FYI - A note regarding DHCPv6 from Interop 2011 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, 17 May 2011 12:14:04 -0000 --bcaec548a5032ac57904a377b592 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Yeah, drives me crazy when I have to switch back and forth often. I was referring to adding mac address to the relay forw msg, of course. I recall someone on the list last year, from UC Davis maybe?, that wanted hwaddr in DHCPv6, and he asked about writing a proposal to allow it to be added to relay forward messages. The response was not great IIRC, which was why I wa= s throwing it out there and ducking. I think he wanted to assign leases using hwaddr. But peer address is along the same lines, I think: something that indicates that although the DUID appears to have been serviced before, the server may want to throw in question whether or not it's looking at the device it thinks it's looking at. The idea was if the relay hands you the hardware address of the device, you could check that against the DUID you've service= d and make some assumptions. I'm not recommending any of this, though, just considering the possibilities. - Bud On Thu, May 12, 2011 at 1:15 AM, Bernie Volz (volz) wrote: > Bud =85 Wrong protocol =85 you are thinking DHCPv4 not DHCPv6 =85 Relay-F= orward > is used in DHCPv6. > > > > Yeah, I was thinking the peer-address might have been useful but at least > in some cases it was not. This seemed very odd to me (it was also odd tha= t > the DUID the Windows system created was not based on the mac address of t= he > interface). But I just didn=92t have the time to diagnose it further. > > > > I might have some additional data to help but it will be a while before I > can fully analyze it. > > > > - Bernie > > > > *From:* Ted Lemon [mailto:Ted.Lemon@nominum.com] > *Sent:* Wednesday, May 11, 2011 6:53 PM > *To:* Bud Millwood > > *Cc:* Bernie Volz (volz); dhcwg@ietf.org; Kim Kinnear (kkinnear); Ralph > Droms (rdroms); Brzozowski, John > *Subject:* Re: [dhcwg] FYI - A note regarding DHCPv6 from Interop 2011 > > > > On May 11, 2011, at 10:51 AM, Bud Millwood wrote: > > That said, relay agents that add hardware address to option 82 could make > this easier to detect when relays are present. Just sayin'. :) > > > > Huh? > > > --bcaec548a5032ac57904a377b592 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Ye= ah, drives me crazy when I have to switch back and forth often. I was refer= ring to adding mac address to the relay forw msg, of course. I recall someo= ne on the list last year, from UC Davis maybe?, that wanted hwaddr in DHCPv= 6, and he asked about writing a proposal to allow it to be added to relay f= orward messages. The response was not great IIRC, which was why I was throw= ing it out there and ducking. I think he wanted to assign leases using hwad= dr.

But peer address is along the same lines, I think: something= that indicates that although the DUID appears to have been serviced before= , the server may want to throw in question whether or not it's looking = at the device it thinks it's looking at. The idea was if the relay hand= s you the hardware address of the device, you could check that against the = DUID you've serviced and make some assumptions.

I'm not recommending any of this, though, just cons= idering the possibilities.

- Bud


On Thu, May 12, 2011 at 1:15 AM, Bernie Volz (volz) = <volz@cisco.com&= gt; wrote:

Bud =85 Wrong protocol =85 y= ou are thinking DHCPv4 not DHCPv6 =85 Relay-Forward is used in DHCPv6.

=A0

Yeah,= I was thinking the peer-address might have been useful but at least in som= e cases it was not. This seemed very odd to me (it was also odd that the DU= ID the Windows system created was not based on the mac address of the inter= face). But I just didn=92t have the time to diagnose it further.

=A0

I might have some additional data to help but it will be a while before= I can fully analyze it.

=A0

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 <= /span>Bernie

=A0

From: Ted Lemon [mailto:= Ted.Lemon@nominu= m.com]
Sent: Wednesday, May 11, 2011 6:53 PM
To: Bud Millwood


Cc: Bernie Volz (volz); dhcwg@ietf.org; Kim Kinnear (kkinn= ear); Ralph Droms (rdroms); Brzozowski, John
Subject: Re: [dhcwg] FYI - A note regarding = DHCPv6 from Interop 2011

=A0=

On May 11, 2011, at 10:51 AM, Bud Mill= wood wrote:

That said, relay agents that add= hardware address to option 82 could make this easier to detect when relays= are present. Just sayin'. :)

=A0

Huh?

=A0


--bcaec548a5032ac57904a377b592-- From tjc@ecs.soton.ac.uk Tue May 17 05:18:40 2011 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 F387DE0729 for ; Tue, 17 May 2011 05:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EBJUHPkHEg32 for ; Tue, 17 May 2011 05:18:38 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 5818FE0769 for ; Tue, 17 May 2011 05:18:37 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p4HCISmQ009312; Tue, 17 May 2011 13:18:28 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk p4HCISmQ009312 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1305634708; bh=lKwGOPFcHi2O1mK7t7bNhzKKoiE=; h=Subject:Mime-Version:From:In-Reply-To:Date:Cc:References:To; b=mkTXDo+5hYOPmg28AjvhJrKxDQVvn6BXFgCEOZlWR2PFk2WbiDeVv0+3AbOP/dgM0 C3Qht54lP9cmBypWH9VwQuLMCYCiHkqNlklpLrnIJUJI9NK5pSOsBe6cAPOHtuV/Wt 50mFAzAvzofQuT/5FLNbWginITSHrHxXiyEaLMr8= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP id n4GDIR0035640943qn ret-id none; Tue, 17 May 2011 13:18:28 +0100 Received: from [192.168.1.14] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p4HCI21f012231 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 17 May 2011 13:18:02 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-9-909967865 From: Tim Chown In-Reply-To: Date: Tue, 17 May 2011 13:18:02 +0100 Message-ID: References: <99DF3B00-534F-4CA7-879B-8B64531C2513@nominum.com> <5644B85E-822F-4F6C-8390-166A301E90EB@ecs.soton.ac.uk> To: Bud Millwood , Chuck Anderson X-Mailer: Apple Mail (2.1084) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=n4GDIR003564094300; tid=n4GDIR0035640943qn; client=relay,ipv6; mail=; rcpt=; nrcpt=6:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: p4HCISmQ009312 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: dhcwg@ietf.org, "Kim Kinnear \(kkinnear\)" , "Bernie Volz \(volz\)" , "Ralph Droms \(rdroms\)" Subject: Re: [dhcwg] FYI - A note regarding DHCPv6 from Interop 2011 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, 17 May 2011 12:18:40 -0000 --Apple-Mail-9-909967865 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 17 May 2011, at 13:14, Bud Millwood wrote: > Yeah, drives me crazy when I have to switch back and forth often. I = was referring to adding mac address to the relay forw msg, of course. I = recall someone on the list last year, from UC Davis maybe?, that wanted = hwaddr in DHCPv6, and he asked about writing a proposal to allow it to = be added to relay forward messages. The response was not great IIRC, = which was why I was throwing it out there and ducking. I think he wanted = to assign leases using hwaddr. It was Chuck, who I've copied explicitly. I had heard the same from = staff locally and at other universities. >=20 > But peer address is along the same lines, I think: something that = indicates that although the DUID appears to have been serviced before, = the server may want to throw in question whether or not it's looking at = the device it thinks it's looking at. The idea was if the relay hands = you the hardware address of the device, you could check that against the = DUID you've serviced and make some assumptions. >=20 > I'm not recommending any of this, though, just considering the = possibilities. We now have the new DUID-UUID method. Tim >=20 > - Bud >=20 >=20 > On Thu, May 12, 2011 at 1:15 AM, Bernie Volz (volz) = wrote: > Bud =85 Wrong protocol =85 you are thinking DHCPv4 not DHCPv6 =85 = Relay-Forward is used in DHCPv6. >=20 > =20 > Yeah, I was thinking the peer-address might have been useful but at = least in some cases it was not. This seemed very odd to me (it was also = odd that the DUID the Windows system created was not based on the mac = address of the interface). But I just didn=92t have the time to diagnose = it further. >=20 > =20 > I might have some additional data to help but it will be a while = before I can fully analyze it. >=20 > =20 > - Bernie >=20 > =20 > From: Ted Lemon [mailto:Ted.Lemon@nominum.com]=20 > Sent: Wednesday, May 11, 2011 6:53 PM > To: Bud Millwood >=20 >=20 > Cc: Bernie Volz (volz); dhcwg@ietf.org; Kim Kinnear (kkinnear); Ralph = Droms (rdroms); Brzozowski, John > Subject: Re: [dhcwg] FYI - A note regarding DHCPv6 from Interop 2011 >=20 > =20 > On May 11, 2011, at 10:51 AM, Bud Millwood wrote: >=20 > That said, relay agents that add hardware address to option 82 could = make this easier to detect when relays are present. Just sayin'. :) >=20 > =20 > Huh? >=20 > =20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg --Apple-Mail-9-909967865 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Yeah, = drives me crazy when I have to switch back and forth often. I was = referring to adding mac address to the relay forw msg, of course. I = recall someone on the list last year, from UC Davis maybe?, that wanted = hwaddr in DHCPv6, and he asked about writing a proposal to allow it to = be added to relay forward messages. The response was not great IIRC, = which was why I was throwing it out there and ducking. I think he wanted = to assign leases using hwaddr.

It was Chuck, = who I've copied explicitly.  I had heard the same from staff = locally and at other universities.

But peer address is along the same lines, I think: = something that indicates that although the DUID appears to have been = serviced before, the server may want to throw in question whether or not = it's looking at the device it thinks it's looking at. The idea was if = the relay hands you the hardware address of the device, you could check = that against the DUID you've serviced and make some assumptions.

I'm not recommending any of this, though, just = considering the possibilities.

We = now have the new DUID-UUID = method.

Tim


- = Bud


On Thu, May 12, 2011 at 1:15 = AM, Bernie Volz (volz) <volz@cisco.com> = wrote:

Bud =85 Wrong protocol =85 = you are thinking DHCPv4 not DHCPv6 =85 Relay-Forward is used in = DHCPv6.

 

Yeah, I was thinking the = peer-address might have been useful but at least in some cases it was = not. This seemed very odd to me (it was also odd that the DUID the = Windows system created was not based on the mac address of the = interface). But I just didn=92t have the time to diagnose it = further.

 

I might have some additional = data to help but it will be a while before I can fully analyze = it.

 

-          = Bernie

 

From: Ted Lemon [mailto:Ted.Lemon@nominum.com]
Sent: Wednesday, May 11, 2011 6:53 PM
To: Bud = Millwood


Cc: Bernie Volz (volz); = dhcwg@ietf.org; = Kim Kinnear (kkinnear); Ralph Droms (rdroms); Brzozowski, John
Subject: Re: [dhcwg] FYI - A note = regarding DHCPv6 from Interop 2011

 

On May 11, 2011, at 10:51 AM, Bud Millwood = wrote:

That said, relay agents that add hardware address to option 82 could = make this easier to detect when relays are present. Just sayin'. = :)

 

Huh?

 

_______________________________________________
dhcwg mailing = list
dhcwg@ietf.org
https://www.ietf.org/= mailman/listinfo/dhcwg

= --Apple-Mail-9-909967865-- From budmillwood@gmail.com Tue May 17 05:48:29 2011 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 8FDE3E0769 for ; Tue, 17 May 2011 05:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.448 X-Spam-Level: X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2m6sOCs0VkE8 for ; Tue, 17 May 2011 05:48:29 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0E766E074D for ; Tue, 17 May 2011 05:48:28 -0700 (PDT) Received: by vws12 with SMTP id 12so362344vws.31 for ; Tue, 17 May 2011 05:48:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=f0olAu193DM7LW29kbrIVWrsHUiKEnyp3p+ZZuHA7JM=; b=JCymW22eWz7M+Uhd9nL7SWpj+Yb3wv2bJ+tV88T7xug1CsyfoHwowMLgKLez0WEnYs VDjB8GITc+4lAUb42SR9VClNV5xE9hkVshL+qwg1iSdZbq92YKMtbYiQrMGcj8T/xtuR otAzRC2r+naSFFxyHUT6qiRqMnktGkGlWc7+Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=qaekMUpYhofxqJDVLlJwfZDwyxy4GNgBp1LbZUYOhSQxUJV21lPu8AfTCKaKMyqRyy sDFDY4MdM7RafU6onaUVMRXAmijvjur4NcAqBVpvf9ZZJH20IZtFHZJsVoxpP4NAcxcK N9lpm8Ly7DPQ+7+OYHmjKOXiidLb6n/EIXxEg= MIME-Version: 1.0 Received: by 10.52.182.35 with SMTP id eb3mr830689vdc.69.1305636508102; Tue, 17 May 2011 05:48:28 -0700 (PDT) Received: by 10.52.113.101 with HTTP; Tue, 17 May 2011 05:48:28 -0700 (PDT) In-Reply-To: References: <99DF3B00-534F-4CA7-879B-8B64531C2513@nominum.com> <5644B85E-822F-4F6C-8390-166A301E90EB@ecs.soton.ac.uk> Date: Tue, 17 May 2011 14:48:28 +0200 Message-ID: From: Bud Millwood To: Tim Chown Content-Type: multipart/alternative; boundary=bcaec548a82b4571e904a37830ed Cc: "Bernie Volz \(volz\)" , "Ralph Droms \(rdroms\)" , Ted.Lemon@nominum.com, dhcwg@ietf.org, Chuck Anderson , "Kim Kinnear \(kkinnear\)" Subject: Re: [dhcwg] FYI - A note regarding DHCPv6 from Interop 2011 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, 17 May 2011 12:48:29 -0000 --bcaec548a82b4571e904a37830ed Content-Type: text/plain; charset=ISO-8859-1 > > We now have the new DUID-UUID method. > Nice, I hadn't seen that. Is it generally desirable, then, to enforce policies based on DUID *type* at the DHCP server? - Bud --bcaec548a82b4571e904a37830ed Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
We now have the new DUID-U= UID method.

Nice, I hadn&= #39;t seen that. Is it generally desirable, then, to enforce policies based= on DUID *type* at the DHCP server?

- Bud

--bcaec548a82b4571e904a37830ed-- From rdroms.ietf@gmail.com Tue May 17 09:16:07 2011 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 01A94E06C8 for ; Tue, 17 May 2011 09:16:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GpcCk9oa4K6P for ; Tue, 17 May 2011 09:16:06 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 2BAF6E0658 for ; Tue, 17 May 2011 09:16:06 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.65,226,1304294400"; d="scan'208";a="358824258" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-2.cisco.com with ESMTP; 17 May 2011 16:16:05 +0000 Received: from sjc-vpnasa-183.cisco.com (sjc-vpnasa-183.cisco.com [10.21.104.183]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p4HGG2hD028447; Tue, 17 May 2011 16:16:03 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: Date: Tue, 17 May 2011 18:16:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5C39EDA6-6F4A-48A8-9426-0AB67805D73E@gmail.com> References: <067E6CE33034954AAC05C9EC85E2577C04905E0E@XMB-RCD-111.cisco.com> <9105F293-1C25-4546-85B0-CF1E1A035CD9@nominum.com> To: Leaf yeh X-Mailer: Apple Mail (2.1084) Cc: "dhcwg@ietf.orgGroup Group" , "Bernie Volz \(volz\)" , Rajiv Asati , Ralph Droms , Lemon Ted Subject: Re: [dhcwg] WG adoption of draft-asati-dhc-relay-agent-config-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: Tue, 17 May 2011 16:16:07 -0000 On May 16, 2011, at 1:10 PM 5/16/11, Leaf yeh wrote: > Ted - My suggestion was to put an ORO in the Relay-Forw message and = have the server send back options that way, rather than defining a new = container. Although having said that, I now feel the need to step back a = pace. It doesn't actually make sense to piggyback this functionality on = top of a DHCP client message. In the particular use case in mind for the option, piggybacking on a = client message does make sense because the config info depends on the = client ID. > 2 more question on the draft-asati: >=20 > a. Not quite sure this draft will cover DHCPv6 per the format of the = new proposed option in Section 4 and the description on behavior of = Relay in Section 5; Yes, the document needs more detail for DHCPv6 operation. > b. Supposed the new option proposed in this draft does piggyback on = top of a DHCP client message per the description on behavior of Relay in = Section 5, right? Not sure what you're asking? - Ralph >=20 >=20 > Best Regards, > Leaf >=20 >=20 >=20 > PS.=20 >=20 > draft-asati-dhc-relay-agent-config-00 >=20 > Section 5.1 > The relay agent adds the DHCP relay agent configuration option (& = needed sub-options) in the relayed message to request the relay agent = side configuration information from the server...A relay agent adding a = Relay Agent Configuration Information Option MUST add it as the last = option (but before 'End Option' 255, if present) or the second last = option, if option 82 is present, in the DHCP options field of any = recognized BOOTP or DHCP packet forwarded from a client to a = server...The relay agent MUST remove the relay agent configuration = option from the DHCP response and forward the remaining response to the = client. >=20 > Section 5.3 > ... The new option defined in this document is never passed to the = client... >=20 >=20 >=20 > -----Original Message----- > From: Ted Lemon [mailto:Ted.Lemon@nominum.com]=20 > Sent: Saturday, May 14, 2011 2:26 AM > To: Leaf yeh > Cc: dhcwg@ietf.org; Bernie Volz > Subject: Re: [dhcwg] WG adoption of = draft-asati-dhc-relay-agent-config-00 >=20 > On May 12, 2011, at 4:07 AM, Leaf yeh wrote: >> 1. Do we really need a new option with new structure or architecture = for the relay configuration in the case of IPv4 & IPv6? >> 2. Would the 2nd draft raise a reasonable solution for BGP/MPLS = IP/VPN (RFC4364) per the section 1 & 3 of this draft (draft-asati)? >=20 > I think the use case addressed by the draft does require some enabling = extension. My suggestion was to put an ORO in the Relay-Forw message = and have the server send back options that way, rather than defining a = new container. >=20 > Although having said that, I now feel the need to step back a pace. = It doesn't actually make sense to piggyback this functionality on top of = a DHCP client message. >=20 > In any case, none of this is germane to the question of whether or not = this is work the working group ought to do. Part of the work of the = working group is figuring out the right solution to the problem. The = question in the call for adoption is, do we think this is work that is = worth doing? >=20 From wwwrun@rfc-editor.org Tue May 17 10:57:40 2011 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 DC44DE0746; Tue, 17 May 2011 10:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.155 X-Spam-Level: X-Spam-Status: No, score=-102.155 tagged_above=-999 required=5 tests=[AWL=-0.155, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TGIK3pZwtgye; Tue, 17 May 2011 10:57:40 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id 4C852E0748; Tue, 17 May 2011 10:57:40 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 403A6E0781; Tue, 17 May 2011 10:57:40 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110517175740.403A6E0781@rfc-editor.org> Date: Tue, 17 May 2011 10:57:40 -0700 (PDT) Cc: dhcwg@ietf.org, rfc-editor@rfc-editor.org Subject: [dhcwg] RFC 6221 on Lightweight DHCPv6 Relay Agent 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, 17 May 2011 17:57:41 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6221 Title: Lightweight DHCPv6 Relay Agent Author: D. Miles, Ed., S. Ooghe, W. Dec, S. Krishnan, A. Kavanagh Status: Standards Track Stream: IETF Date: May 2011 Mailbox: david.miles@alcatel-lucent.com, sven.ooghe@alcatel-lucent.com, wdec@cisco.com, suresh.krishnan@ericsson.com, alan.kavanagh@ericsson.com Pages: 17 Characters: 28471 Updates: RFC3315 I-D Tag: draft-ietf-dhc-dhcpv6-ldra-03.txt URL: http://www.rfc-editor.org/rfc/rfc6221.txt This document proposes a Lightweight DHCPv6 Relay Agent (LDRA) that is used to insert relay agent options in DHCPv6 message exchanges identifying client-facing interfaces. The LDRA can be implemented in existing access nodes (such as Digital Subscriber Link Access Multiplexers (DSLAMs) and Ethernet switches) that do not support IPv6 control or routing functions. [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 leaf.y.yeh@huawei.com Tue May 17 18:49:41 2011 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 D94EEE06A4 for ; Tue, 17 May 2011 18:49:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YqY+xDk4z6YM for ; Tue, 17 May 2011 18:49:41 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 9DF9FE0659 for ; Tue, 17 May 2011 18:49:40 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLD0079QBQH8X@szxga04-in.huawei.com> for dhcwg@ietf.org; Wed, 18 May 2011 09:49:29 +0800 (CST) Received: from szxeml206-edg.china.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLD00L6ZBQH5Q@szxga04-in.huawei.com> for dhcwg@ietf.org; Wed, 18 May 2011 09:49:29 +0800 (CST) Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 18 May 2011 09:49:25 +0800 Received: from SZXEML514-MBX.china.huawei.com ([169.254.2.14]) by SZXEML401-HUB.china.huawei.com ([10.82.67.31]) with mapi id 14.01.0270.001; Wed, 18 May 2011 09:49:28 +0800 Date: Wed, 18 May 2011 01:49:28 +0000 From: Leaf yeh In-reply-to: <5C39EDA6-6F4A-48A8-9426-0AB67805D73E@gmail.com> X-Originating-IP: [10.70.39.133] To: Ralph Droms Message-id: MIME-version: 1.0 Content-type: text/plain; charset=Windows-1252 Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: [dhcwg] WG adoption of draft-asati-dhc-relay-agent-config-00 Thread-index: AcvwvmvXzCHd+ukFSkSNyX8FCnzm+gYI7ONAAZfrWYAAEvCUcAABKYoAACyfDpAARN1xAACHr5XQADzw1wAAI1iSMA== X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <067E6CE33034954AAC05C9EC85E2577C04905E0E@XMB-RCD-111.cisco.com> <9105F293-1C25-4546-85B0-CF1E1A035CD9@nominum.com> <5C39EDA6-6F4A-48A8-9426-0AB67805D73E@gmail.com> Cc: "dhcwg@ietf.orgGroup Group" , Rajiv Asati , Lemon Ted , "Bernie Volz \(volz\)" Subject: Re: [dhcwg] WG adoption of draft-asati-dhc-relay-agent-config-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: Wed, 18 May 2011 01:49:42 -0000 Ted - It doesn't actually make sense to piggyback this functionality on top of a DHCP client message. Leaf - b. Supposed the new option proposed in this draft does piggyback on top of a DHCP client message per the description on behavior of Relay in Section 5, right? Ralph - Not sure what you're asking? Sorry for the confusion. I was trying to make sure whether this draft will insist adopting the method of the called 'piggyback' option, which is the same method as the ORO, though I can accept this concept in some use cases. Best Regards, Leaf -----Original Message----- From: Ralph Droms [mailto:rdroms.ietf@gmail.com] Sent: Wednesday, May 18, 2011 12:16 AM To: Leaf yeh Cc: Ralph Droms; Lemon Ted; dhcwg@ietf.orgGroup Group; Bernie Volz (volz); Rajiv Asati Subject: Re: [dhcwg] WG adoption of draft-asati-dhc-relay-agent-config-00 On May 16, 2011, at 1:10 PM 5/16/11, Leaf yeh wrote: > Ted - My suggestion was to put an ORO in the Relay-Forw message and have the server send back options that way, rather than defining a new container. Although having said that, I now feel the need to step back a pace. It doesn't actually make sense to piggyback this functionality on top of a DHCP client message. In the particular use case in mind for the option, piggybacking on a client message does make sense because the config info depends on the client ID. > 2 more question on the draft-asati: > > a. Not quite sure this draft will cover DHCPv6 per the format of the new proposed option in Section 4 and the description on behavior of Relay in Section 5; Yes, the document needs more detail for DHCPv6 operation. > b. Supposed the new option proposed in this draft does piggyback on top of a DHCP client message per the description on behavior of Relay in Section 5, right? Not sure what you're asking? - Ralph > > > Best Regards, > Leaf > > > > PS. > > draft-asati-dhc-relay-agent-config-00 > > Section 5.1 > The relay agent adds the DHCP relay agent configuration option (& needed sub-options) in the relayed message to request the relay agent side configuration information from the server...A relay agent adding a Relay Agent Configuration Information Option MUST add it as the last option (but before 'End Option' 255, if present) or the second last option, if option 82 is present, in the DHCP options field of any recognized BOOTP or DHCP packet forwarded from a client to a server...The relay agent MUST remove the relay agent configuration option from the DHCP response and forward the remaining response to the client. > > Section 5.3 > ... The new option defined in this document is never passed to the client... > > > > -----Original Message----- > From: Ted Lemon [mailto:Ted.Lemon@nominum.com] > Sent: Saturday, May 14, 2011 2:26 AM > To: Leaf yeh > Cc: dhcwg@ietf.org; Bernie Volz > Subject: Re: [dhcwg] WG adoption of draft-asati-dhc-relay-agent-config-00 > > On May 12, 2011, at 4:07 AM, Leaf yeh wrote: >> 1. Do we really need a new option with new structure or architecture for the relay configuration in the case of IPv4 & IPv6? >> 2. Would the 2nd draft raise a reasonable solution for BGP/MPLS IP/VPN (RFC4364) per the section 1 & 3 of this draft (draft-asati)? > > I think the use case addressed by the draft does require some enabling extension. My suggestion was to put an ORO in the Relay-Forw message and have the server send back options that way, rather than defining a new container. > > Although having said that, I now feel the need to step back a pace. It doesn't actually make sense to piggyback this functionality on top of a DHCP client message. > > In any case, none of this is germane to the question of whether or not this is work the working group ought to do. Part of the work of the working group is figuring out the right solution to the problem. The question in the call for adoption is, do we think this is work that is worth doing? > From Ted.Lemon@nominum.com Wed May 18 06:14:33 2011 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 03A0AE06F5 for ; Wed, 18 May 2011 06:14:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.421 X-Spam-Level: X-Spam-Status: No, score=-106.421 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nNa+c3kYOZ2l for ; Wed, 18 May 2011 06:14:32 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id 46EFBE06CB for ; Wed, 18 May 2011 06:14:31 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKTdPGNx6SR+dOjRsH11YVFPLprbAWI8i6@postini.com; Wed, 18 May 2011 06:14:32 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 308291B848E for ; Wed, 18 May 2011 06:14:30 -0700 (PDT) Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 15F6D190052; Wed, 18 May 2011 06:14:30 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from vpna-148.vpn.nominum.com (64.89.227.148) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 18 May 2011 06:14:29 -0700 MIME-Version: 1.0 (Apple Message framework v1227) Content-Type: text/plain; charset="us-ascii" From: Ted Lemon In-Reply-To: <1836BEF9-0739-4783-9A49-15F01D645F5D@employees.org> Date: Wed, 18 May 2011 09:14:25 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <0B11777A-E188-4933-8B7C-EFCA509EE35D@nominum.com> References: <94200415-3C9D-4C61-88AB-42A6D0E11649@nominum.com> <4DC864D1.8010101@gmail.com> <20110511184158.GB4138@shell-too.nominum.com> <68614430-1044-45EE-9B64-354284B13D87@gmail.com> <1836BEF9-0739-4783-9A49-15F01D645F5D@employees.org> To: Ole Troan X-Mailer: Apple Mail (2.1227) Cc: dhcwg@ietf.org Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-pd-exclude-01 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, 18 May 2011 13:14:33 -0000 On May 16, 2011, at 7:09 AM, Ole Troan wrote: > can we do another try at better text for the current encoding, or does = the working group prefer the explicit coding in option 2? The text is written in the passive voice, and is descriptive rather than = prescriptive. I would suggest trying to figure out a way to say "to = make a PD_EXCLUDE option, do ..." and "to use a PD_EXCLUDE option, do = ..." It might be helpful to express it as bit arithmetic. Start from = a piece of code that does it, and try to describe what the code does. = I agree with SJ that as written, the description is going to be = difficult to understand. From Ted.Lemon@nominum.com Wed May 18 06:15:13 2011 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 A14B5E06F5 for ; Wed, 18 May 2011 06:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.438 X-Spam-Level: X-Spam-Status: No, score=-106.438 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MqVy7W4KFILN for ; Wed, 18 May 2011 06:15:13 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id E6564E06CB for ; Wed, 18 May 2011 06:15:12 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKTdPGYOaROA530mBrq7QKhTv92Lz7v1iv@postini.com; Wed, 18 May 2011 06:15:12 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 EFD561B8431 for ; Wed, 18 May 2011 06:15:11 -0700 (PDT) Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id E987F190052; Wed, 18 May 2011 06:15:11 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from vpna-148.vpn.nominum.com (64.89.227.148) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 18 May 2011 06:15:11 -0700 MIME-Version: 1.0 (Apple Message framework v1227) Content-Type: multipart/alternative; boundary="Apple-Mail=_E9648C72-89DA-4D4A-8CC6-69D2ED2B49E9" From: Ted Lemon In-Reply-To: Date: Wed, 18 May 2011 09:15:10 -0400 Message-ID: References: To: "M A, Aleem Chisti" X-Mailer: Apple Mail (2.1227) Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] DHCPv6 RFC 3315 Clarification - T1 and T2 timer values in IA_NA option 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, 18 May 2011 13:15:13 -0000 --Apple-Mail=_E9648C72-89DA-4D4A-8CC6-69D2ED2B49E9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="windows-1252" On May 17, 2011, at 6:07 AM, M A, Aleem Chisti wrote: > However, this RFC doesn=92t mention about, what should be the client = behavior when T1 is equal to T2. As far as I can see, it's not a problem for T1 to be equal to T2. Are = you aware of a concern? --Apple-Mail=_E9648C72-89DA-4D4A-8CC6-69D2ED2B49E9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="windows-1252"
However, this RFC doesn=92t mention about, what should be = the client behavior when T1 is equal to = T2.

As far as I can see, it's = not a problem for T1 to be equal to T2.   Are you aware of a = concern?


= --Apple-Mail=_E9648C72-89DA-4D4A-8CC6-69D2ED2B49E9-- From Ted.Lemon@nominum.com Wed May 18 06:21:42 2011 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 14CD4E070E for ; Wed, 18 May 2011 06:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.453 X-Spam-Level: X-Spam-Status: No, score=-106.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QbTwi0GglPqO for ; Wed, 18 May 2011 06:21:41 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id 4D341E06FB for ; Wed, 18 May 2011 06:21:40 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKTdPH5F0VgLYTaP5LvdQD6Y0oxNK3wJWu@postini.com; Wed, 18 May 2011 06:21:41 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 0FF9EF8080 for ; Wed, 18 May 2011 06:21:40 -0700 (PDT) Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 0556E190052; Wed, 18 May 2011 06:21:40 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from vpna-148.vpn.nominum.com (64.89.227.148) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 18 May 2011 06:21:39 -0700 MIME-Version: 1.0 (Apple Message framework v1227) Content-Type: text/plain; charset="us-ascii" From: Ted Lemon In-Reply-To: Date: Wed, 18 May 2011 09:21:35 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <067E6CE33034954AAC05C9EC85E2577C04905E0E@XMB-RCD-111.cisco.com> <9105F293-1C25-4546-85B0-CF1E1A035CD9@nominum.com> To: Leaf yeh X-Mailer: Apple Mail (2.1227) Cc: "dhcwg@ietf.org" , "Bernie Volz \(volz\)" , "rdroms.ietf@gmail.com" Subject: Re: [dhcwg] WG adoption of draft-asati-dhc-relay-agent-config-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: Wed, 18 May 2011 13:21:42 -0000 On May 16, 2011, at 7:10 AM, Leaf yeh wrote: > a. Not quite sure this draft will cover DHCPv6 per the format of the = new proposed option in Section 4 and the description on behavior of = Relay in Section 5; Yes, getting DHCPv4 and DHCPv6 confused seems to be a theme this week... = :) > b. Supposed the new option proposed in this draft does piggyback on = top of a DHCP client message per the description on behavior of Relay in = Section 5, right? Right. The thing is, configuring the relay agent is really not = something that needs to happen at the same time as configuring the = client. Why isn't the relay agent simply sending a configuration = request to the server at its own convenience, independent of any = communication from the client? From iesg-secretary@ietf.org Wed May 18 07:01:18 2011 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 96CD6E0766; Wed, 18 May 2011 07:01:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PwGNPsNKVYkF; Wed, 18 May 2011 07:01:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35B9FE075C; Wed, 18 May 2011 07:01:18 -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: 3.54 Message-ID: <20110518140118.20509.39731.idtracker@ietfa.amsl.com> Date: Wed, 18 May 2011 07:01:18 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] Last Call: (Relay-Supplied DHCP Options) to Proposed Standard X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 14:01:18 -0000 The IESG has received a request from the Dynamic Host Configuration WG (dhc) to consider the following document: - 'Relay-Supplied DHCP Options' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-06-01. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes a mechanism whereby a DHCPv6 relay agent can provide options to a DHCPv6 server that the DHCPv6 server can then provide to the DHCPv6 client in certain restricted cases where this is necessary. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-relay-supplied-options/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-relay-supplied-options/ No IPR declarations have been submitted directly on this I-D. From iesg-secretary@ietf.org Wed May 18 08:46:59 2011 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 1F62EE0724; Wed, 18 May 2011 08:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rq-IgZviUskI; Wed, 18 May 2011 08:46:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B7D5E06FB; Wed, 18 May 2011 08:46:58 -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: 3.54 Message-ID: <20110518154658.20031.88695.idtracker@ietfa.amsl.com> Date: Wed, 18 May 2011 08:46:58 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] Last Call: (Definition of the UUID-based DHCPv6 Unique Identifier (DUID-UUID)) to Proposed Standard X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 15:46:59 -0000 The IESG has received a request from the Dynamic Host Configuration WG (dhc) to consider the following document: - 'Definition of the UUID-based DHCPv6 Unique Identifier (DUID-UUID)' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-06-01. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a new DHCPv6 Unique Identifier (DUID) type, called DUID-UUID. DUID-UUIDs are derived from the already standardized UUID format. DUID-UUID makes it possible for devices to use UUIDs to identify themselves to DHC servers and vice versa. UUIDs are globally unique and readily available on many systems, making them convenient identifiers to leverage within DHCP. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dhc-duid-uuid/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dhc-duid-uuid/ No IPR declarations have been submitted directly on this I-D. From m.aleem-chisti@hp.com Wed May 18 23:44:36 2011 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 ECCFDE0713 for ; Wed, 18 May 2011 23:44:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.476 X-Spam-Level: X-Spam-Status: No, score=-106.476 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DzlVfzV4rDip for ; Wed, 18 May 2011 23:44:36 -0700 (PDT) Received: from g6t0184.atlanta.hp.com (g6t0184.atlanta.hp.com [15.193.32.61]) by ietfa.amsl.com (Postfix) with ESMTP id CC33BE0681 for ; Wed, 18 May 2011 23:44:35 -0700 (PDT) Received: from G6W0640.americas.hpqcorp.net (g6w0640.atlanta.hp.com [16.230.34.76]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g6t0184.atlanta.hp.com (Postfix) with ESMTPS id E1776C468; Thu, 19 May 2011 06:44:34 +0000 (UTC) Received: from G1W0395.americas.hpqcorp.net (16.236.31.0) by G6W0640.americas.hpqcorp.net (16.230.34.76) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 19 May 2011 06:43:37 +0000 Received: from GVW1352EXA.americas.hpqcorp.net ([16.238.8.126]) by G1W0395.americas.hpqcorp.net ([16.236.31.0]) with mapi; Thu, 19 May 2011 06:43:36 +0000 From: "M A, Aleem Chisti" To: Ted Lemon Date: Thu, 19 May 2011 06:43:30 +0000 Thread-Topic: [dhcwg] DHCPv6 RFC 3315 Clarification - T1 and T2 timer values in IA_NA option Thread-Index: AcwVXaDaFSqA0wRyTqSSSYq52uh6HAAkeY1Q Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_BCCD681151F89347B4D7C5FE64A651D32E04A749C9GVW1352EXAame_" MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] DHCPv6 RFC 3315 Clarification - T1 and T2 timer values in IA_NA option 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, 19 May 2011 06:44:37 -0000 --_000_BCCD681151F89347B4D7C5FE64A651D32E04A749C9GVW1352EXAame_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If T1 is equal to T2 and upon the timer expiry, what message should the cli= ent send; RENEW or REBIND ? 1. What if it sends a RENEW message and if the server which initially sent = a REPLY is no longer present in the network ? How do decide on the number o= f retransmissions of RENEW before sending a REBIND ? 2. Upon timer expiry, if it sends a REBIND message, what if the server whic= h initially sent a REPLY is still present in the network ? From: Ted Lemon [mailto:Ted.Lemon@nominum.com] Sent: Wednesday, May 18, 2011 6:45 PM To: M A, Aleem Chisti Cc: dhcwg@ietf.org Subject: Re: [dhcwg] DHCPv6 RFC 3315 Clarification - T1 and T2 timer values= in IA_NA option On May 17, 2011, at 6:07 AM, M A, Aleem Chisti wrote: However, this RFC doesn't mention about, what should be the client behavior= when T1 is equal to T2. As far as I can see, it's not a problem for T1 to be equal to T2. Are you= aware of a concern? --_000_BCCD681151F89347B4D7C5FE64A651D32E04A749C9GVW1352EXAame_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

If T1 is equal to T2 and = upon the timer expiry, what message should the client send; RENEW or REBIND= ?

 <= /p>

1. What if it sends a REN= EW message and if the server which initially sent a REPLY is no longer pres= ent in the network ? How do decide on the number of retransmissions of RENEW before sending a REBIND ?

 <= /p>

2. Upon timer expiry, if = it sends a REBIND message, what if the server which initially sent a REPLY = is still present in the network ?

 <= /p>

 <= /p>

From: Ted Lemo= n [mailto:Ted.Lemon@nominum.com]
Sent: Wednesday, May 18, 2011 6:45 PM
To: M A, Aleem Chisti
Cc: dhcwg@ietf.org
Subject: Re: [dhcwg] DHCPv6 RFC 3315 Clarification - T1 and T2 timer= values in IA_NA option

 

On May 17, 2011, at 6:07 AM, M A, Aleem Chisti wrote= :

However, this RFC doesn’t mention= about, what should be the client behavior when T1 is equal to T2.

 

As far as I can see, it's not a problem for T1 to be= equal to T2.   Are you aware of a concern?

 

 

--_000_BCCD681151F89347B4D7C5FE64A651D32E04A749C9GVW1352EXAame_-- From akostur@incognito.com Thu May 19 08:38:18 2011 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 CA6EEE0800 for ; Thu, 19 May 2011 08:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bAH1qEQO1nuE for ; Thu, 19 May 2011 08:38:18 -0700 (PDT) Received: from na3sys010aog111.obsmtp.com (na3sys010aog111.obsmtp.com [74.125.245.90]) by ietfa.amsl.com (Postfix) with SMTP id 988F1E0753 for ; Thu, 19 May 2011 08:38:16 -0700 (PDT) Received: from mail-vx0-f179.google.com ([209.85.220.179]) (using TLSv1) by na3sys010aob111.postini.com ([74.125.244.12]) with SMTP ID DSNKTdU5Z8+wd3gtgHWOg/X6i/VsSIvrWav8@postini.com; Thu, 19 May 2011 08:38:17 PDT Received: by vxi40 with SMTP id 40so2068568vxi.10 for ; Thu, 19 May 2011 08:38:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.67.146 with SMTP id n18mr152407vdt.232.1305819495169; Thu, 19 May 2011 08:38:15 -0700 (PDT) Received: by 10.52.185.103 with HTTP; Thu, 19 May 2011 08:38:15 -0700 (PDT) In-Reply-To: References: Date: Thu, 19 May 2011 08:38:15 -0700 Message-ID: From: Andre Kostur To: "M A, Aleem Chisti" Content-Type: multipart/alternative; boundary=20cf307f32e0267e5d04a3a2cb5e Cc: "dhcwg@ietf.org" , Ted Lemon Subject: Re: [dhcwg] DHCPv6 RFC 3315 Clarification - T1 and T2 timer values in IA_NA option 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, 19 May 2011 15:38:18 -0000 --20cf307f32e0267e5d04a3a2cb5e Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I'd say that the device would be expected to transition into the Rebinding state. So #1 isn't an issue, the device immediately starts REBINDing. For #2, if the issuing server is still present, it will REPLY, and the client i= s happy. On Wed, May 18, 2011 at 23:43, M A, Aleem Chisti wro= te: > If T1 is equal to T2 and upon the timer expiry, what message should the > client send; RENEW or REBIND ? > > > > 1. What if it sends a RENEW message and if the server which initially sen= t > a REPLY is no longer present in the network ? How do decide on the number= of > retransmissions of RENEW before sending a REBIND ? > > > > 2. Upon timer expiry, if it sends a REBIND message, what if the server > which initially sent a REPLY is still present in the network ? > > > > > > *From:* Ted Lemon [mailto:Ted.Lemon@nominum.com] > *Sent:* Wednesday, May 18, 2011 6:45 PM > *To:* M A, Aleem Chisti > *Cc:* dhcwg@ietf.org > *Subject:* Re: [dhcwg] DHCPv6 RFC 3315 Clarification - T1 and T2 timer > values in IA_NA option > > > > On May 17, 2011, at 6:07 AM, M A, Aleem Chisti wrote: > > However, this RFC doesn=92t mention about, what should be the client > behavior when T1 is equal to T2. > > > > As far as I can see, it's not a problem for T1 to be equal to T2. Are y= ou > aware of a concern? > > > > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > > --=20 Andre Kostur Senior Software Design Engineer P: 604-678-2864 SIP: 864@incognito.com --20cf307f32e0267e5d04a3a2cb5e Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
I'd say that the device would be expected to transitio= n into the Rebinding state. =A0So #1 isn't an issue, the device immedia= tely starts REBINDing. =A0For #2, if the issuing server is still present, i= t will REPLY, and the client is happy.

On Wed, May 18, 2011 at 23:43, M A, Aleem Ch= isti <m.aleem= -chisti@hp.com> wrote:

If T1= is equal to T2 and upon the timer expiry, what message should the client s= end; RENEW or REBIND ?

=A0

1. Wh= at if it sends a RENEW message and if the server which initially sent a REP= LY is no longer present in the network ? How do decide on the number of ret= ransmissions of RENEW before sending a REBIND ?

=A0

2. Up= on timer expiry, if it sends a REBIND message, what if the server which ini= tially sent a REPLY is still present in the network ?

=A0

=A0

From:= Ted Lemon [mailto:Ted.Lemon@nominum.com]
Sent: Wednesday, May 18, 2011 6:45 PM
To: M A, Aleem Chisti
Cc: dhcwg@ietf.o= rg
Subject: Re: [dhcwg] DHCPv6 RFC 3315 Clarification - T1 and T2 timer= values in IA_NA option

=A0

On May 17, 2011, at 6:07 AM, M A, Aleem Chisti wrote= :

However, this RFC d= oesn=92t mention about, what should be the client behavior when T1 is equal= to T2.

=A0

As far as I can see, it's not a problem for T1 t= o be equal to T2. =A0 Are you aware of a concern?

=A0

=A0


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dhcwg




--
Andre Kostur
Se= nior Software Design Engineer
P: 604-678-2864 =A0SIP: 864@incognito.com


--20cf307f32e0267e5d04a3a2cb5e-- From rangaprasad.sampath@hp.com Fri May 20 09:47:52 2011 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 BF078E06B8 for ; Fri, 20 May 2011 09:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MizJ8nVnampn for ; Fri, 20 May 2011 09:47:51 -0700 (PDT) Received: from g6t0186.atlanta.hp.com (g6t0186.atlanta.hp.com [15.193.32.63]) by ietfa.amsl.com (Postfix) with ESMTP id 31BD8E0651 for ; Fri, 20 May 2011 09:47:50 -0700 (PDT) Received: from G3W0631.americas.hpqcorp.net (g3w0631.americas.hpqcorp.net [16.233.59.15]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g6t0186.atlanta.hp.com (Postfix) with ESMTPS id 027262C98F; Fri, 20 May 2011 16:47:50 +0000 (UTC) Received: from G4W0659.americas.hpqcorp.net (16.234.40.187) by G3W0631.americas.hpqcorp.net (16.233.59.15) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 20 May 2011 16:47:17 +0000 Received: from GVW1162EXB.americas.hpqcorp.net ([16.232.35.134]) by G4W0659.americas.hpqcorp.net ([16.234.40.187]) with mapi; Fri, 20 May 2011 16:47:18 +0000 From: "Sampath, Rangaprasad (HP Networking)" To: "M A, Aleem Chisti" , Ted Lemon Date: Fri, 20 May 2011 16:47:16 +0000 Thread-Topic: [dhcwg] DHCPv6 RFC 3315 Clarification - T1 and T2 timer values in IA_NA option Thread-Index: AcwVXaDaFSqA0wRyTqSSSYq52uh6HAAkeY1QAEdo4jA= Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_B6A10B07C479604C922301A4A4CB3493605631800AGVW1162EXBame_" MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] DHCPv6 RFC 3315 Clarification - T1 and T2 timer values in IA_NA option 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, 20 May 2011 16:47:52 -0000 --_000_B6A10B07C479604C922301A4A4CB3493605631800AGVW1162EXBame_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Could we also treat T1=3D=3DT2 as an invalid case and follow the behavior o= utlined for the T1>T2 case? That would mean that for T1>=3DT2, the client w= ould discard the IA_NA option and process the remainder of the message as t= hough the server had not included the IA_NA option. Regards, Ranga.. From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of M= A, Aleem Chisti Sent: Wednesday, May 18, 2011 11:44 PM To: Ted Lemon Cc: dhcwg@ietf.org Subject: Re: [dhcwg] DHCPv6 RFC 3315 Clarification - T1 and T2 timer values= in IA_NA option If T1 is equal to T2 and upon the timer expiry, what message should the cli= ent send; RENEW or REBIND ? 1. What if it sends a RENEW message and if the server which initially sent = a REPLY is no longer present in the network ? How do decide on the number o= f retransmissions of RENEW before sending a REBIND ? 2. Upon timer expiry, if it sends a REBIND message, what if the server whic= h initially sent a REPLY is still present in the network ? From: Ted Lemon [mailto:Ted.Lemon@nominum.com] Sent: Wednesday, May 18, 2011 6:45 PM To: M A, Aleem Chisti Cc: dhcwg@ietf.org Subject: Re: [dhcwg] DHCPv6 RFC 3315 Clarification - T1 and T2 timer values= in IA_NA option On May 17, 2011, at 6:07 AM, M A, Aleem Chisti wrote: However, this RFC doesn't mention about, what should be the client behavior= when T1 is equal to T2. As far as I can see, it's not a problem for T1 to be equal to T2. Are you= aware of a concern? --_000_B6A10B07C479604C922301A4A4CB3493605631800AGVW1162EXBame_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Could we also treat T1=3D=3DT2 as an invalid case and follow the= behavior outlined for the T1>T2 case? That would mean that for T1>= =3DT2, the client would discard the IA_NA option and process the remainder = of the message as though the server had not included the IA_NA option.=

 

Regards,

Ranga..

&nbs= p;

 

=

From: dhcwg-bounces@ietf.org [mailto:dhcwg= -bounces@ietf.org] On Behalf Of M A, Aleem Chisti
Sent: We= dnesday, May 18, 2011 11:44 PM
To: Ted Lemon
Cc: dhcwg@= ietf.org
Subject: Re: [dhcwg] DHCPv6 RFC 3315 Clarification - T1 = and T2 timer values in IA_NA option

 

If T1 is eq= ual to T2 and upon the timer expiry, what message should the client send; R= ENEW or REBIND ?

&nb= sp;

1. What if it sends a RENEW= message and if the server which initially sent a REPLY is no longer presen= t in the network ? How do decide on the number of retransmissions of RENEW = before sending a REBIND ?

=  

2. Upon timer expir= y, if it sends a REBIND message, what if the server which initially sent a = REPLY is still present in the network ?

 

 

From: Ted Lemon = [mailto:Ted.Lemon@nominum.com]
Sent: Wednesday, May 18, 2011 6:4= 5 PM
To: M A, Aleem Chisti
Cc: dhcwg@ietf.org
Sub= ject: Re: [dhcwg] DHCPv6 RFC 3315 Clarification - T1 and T2 timer value= s in IA_NA option

 

On May 17, 2011, at 6:07 A= M, M A, Aleem Chisti wrote:

However, this RFC doesn&= #8217;t mention about, what should be the client behavior when T1 is equal = to T2.

&n= bsp;

As far as I can see, it's not= a problem for T1 to be equal to T2.   Are you aware of a concern?

 

 

= --_000_B6A10B07C479604C922301A4A4CB3493605631800AGVW1162EXBame_-- From Ted.Lemon@nominum.com Fri May 20 16:32:56 2011 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 E203CE0772 for ; Fri, 20 May 2011 16:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.465 X-Spam-Level: X-Spam-Status: No, score=-106.465 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qJHPziOL8QmE for ; Fri, 20 May 2011 16:32:56 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id 1D342E0699 for ; Fri, 20 May 2011 16:32:55 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKTdb6JtrSbiIcLjOLz3CWDrTqpAwZYteq@postini.com; Fri, 20 May 2011 16:32:56 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 62F4B1B8599 for ; Fri, 20 May 2011 16:32:54 -0700 (PDT) Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 57EF2190052; Fri, 20 May 2011 16:32:54 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from vpna-148.vpn.nominum.com (64.89.227.148) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 20 May 2011 16:32:53 -0700 MIME-Version: 1.0 (Apple Message framework v1227) Content-Type: multipart/alternative; boundary="Apple-Mail=_39152F49-0956-4C8D-855D-9D7FD1D5DA26" From: Ted Lemon In-Reply-To: Date: Fri, 20 May 2011 19:32:50 -0400 Message-ID: References: To: "Sampath, Rangaprasad (HP Networking)" X-Mailer: Apple Mail (2.1227) Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] DHCPv6 RFC 3315 Clarification - T1 and T2 timer values in IA_NA option 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, 20 May 2011 23:32:57 -0000 --Apple-Mail=_39152F49-0956-4C8D-855D-9D7FD1D5DA26 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" On May 20, 2011, at 12:47 PM, Sampath, Rangaprasad (HP Networking) = wrote: > Could we also treat T1=3D=3DT2 as an invalid case and follow the = behavior outlined for the T1>T2 case? That would mean that for T1>=3DT2, = the client would discard the IA_NA option and process the remainder of = the message as though the server had not included the IA_NA option. I think this is a bad idea. Someone reading the spec could easily = conclude that something meaningful would happen if T1=3D=3DT2. It = makes sense to rebind at T1/T2 in that case. Your proposal is very = clearly out of spec; it's possible that some implementor might decide to = violate the spec in the way you propose also, but it's more likely = implementors will go straight to REBIND in this case. If you violate = that spec, your client is probably going to be the only one that fails = to acquire an IP address. Generally speaking, this is a result you're = better off avoiding. --Apple-Mail=_39152F49-0956-4C8D-855D-9D7FD1D5DA26 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii" Could we also treat = T1=3D=3DT2 as an invalid case and follow the behavior outlined for the = T1>T2 case? That would mean that for T1>=3DT2, the client would = discard the IA_NA option and process the remainder of the message as = though the server had not included the IA_NA = option.
I think this is a bad = idea.   Someone reading the spec could easily conclude that = something meaningful would happen if T1=3D=3DT2.   It makes sense = to rebind at T1/T2 in that case.   Your proposal is very clearly = out of spec; it's possible that some implementor might decide to violate = the spec in the way you propose also, but it's more likely implementors = will go straight to REBIND in this case.   If you violate that = spec, your client is probably going to be the only one that fails to = acquire an IP address.   Generally speaking, this is a result = you're better off avoiding.

= --Apple-Mail=_39152F49-0956-4C8D-855D-9D7FD1D5DA26-- From Stephen.Jacob@nominum.com Fri May 20 18:16:44 2011 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 4189EE068B for ; Fri, 20 May 2011 18:16:44 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8hYQR9Z2z+sr for ; Fri, 20 May 2011 18:16:43 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id 638E6E0665 for ; Fri, 20 May 2011 18:16:43 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKTdcSeRqWUd0Tq4Zc6NskX4MHDQIzHkQ8@postini.com; Fri, 20 May 2011 18:16:43 PDT Received: by shell-too.nominum.com (Postfix, from userid 11053) id 66D4CF8106; Fri, 20 May 2011 18:16:41 -0700 (PDT) Date: Fri, 20 May 2011 18:16:41 -0700 From: Stephen Jacob To: Ted Lemon Message-ID: <20110521011641.GB29204@shell-too.nominum.com> Mail-Followup-To: Ted Lemon , "Sampath, Rangaprasad (HP Networking)" , "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] DHCPv6 RFC 3315 Clarification - T1 and T2 timer values in IA_NA option 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, 21 May 2011 01:16:44 -0000 On Fri, May 20, 2011 at 07:32:50PM -0400, Ted Lemon wrote: > On May 20, 2011, at 12:47 PM, Sampath, Rangaprasad (HP Networking) wrote: > > Could we also treat T1==T2 as an invalid case and follow the > > behavior outlined for the T1>T2 case? That would mean that for > > T1>=T2, the client would discard the IA_NA option and process the > > remainder of the message as though the server had not included the > > IA_NA option. > > I think this is a bad idea. Someone reading the spec could easily > conclude that something meaningful would happen if T1==T2. It makes > sense to rebind at T1/T2 in that case. Your proposal is very clearly > out of spec; it's possible that some implementor might decide to > violate the spec in the way you propose also, but it's more likely > implementors will go straight to REBIND in this case. If you violate > that spec, your client is probably going to be the only one that fails > to acquire an IP address. Generally speaking, this is a result > you're better off avoiding. I agree with Ted. I think the obvious result of T1==T2 should be that you go stright to Rebinding. Whether that is via going to Renewing and immediately on to Rebinding or directly is an implementation detail but I fail to see how any other course of action follows the rules or intention of the specification for either DHCPv4 or DHCPv6. Regards, Stephen -- Stephen Jacob | Stephen.Jacob@nominum.com | +1 650 381 6051 Nominum, Inc. | http://www.nominum.com/ | +1 650 381 6000 From bharat_joshi@infosys.com Sun May 22 23:11:40 2011 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 0756FE071A for ; Sun, 22 May 2011 23:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q2fVUq7UJMHn for ; Sun, 22 May 2011 23:11:39 -0700 (PDT) Received: from KECGATE08.infosys.com (kecgate08.infosys.com [122.98.10.33]) by ietfa.amsl.com (Postfix) with ESMTP id AB0FBE06CE for ; Sun, 22 May 2011 23:11:38 -0700 (PDT) X-TM-IMSS-Message-ID: Received: from blrkechub04.ad.infosys.com ([10.66.236.44]) by infosys.com ([122.98.10.33]) with ESMTP (TREND IMSS SMTP Service 7.1) id c2e2944a00150838 ; Mon, 23 May 2011 11:46:38 +0530 Received: from BLRKECMBX02.ad.infosys.com ([10.66.236.22]) by blrkechub04.ad.infosys.com ([10.66.236.44]) with mapi; Mon, 23 May 2011 11:41:36 +0530 From: Bharat Joshi To: Ted Lemon , "dhcwg@ietf.orgWG WG" Date: Mon, 23 May 2011 11:39:59 +0530 Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-dhcpv4-bulk-leasequery-04.txt Thread-Index: AcwP7QdO0zZSIK7/Ri2igmtTBdmk2QJIwRBW Message-ID: <31D55C4D55BEED48A4459EB64567589A115E3C9ED2@BLRKECMBX02.ad.infosys.com> References: <6280FDDC-D655-4FFD-8143-6C320A437F21@fugue.com> In-Reply-To: <6280FDDC-D655-4FFD-8143-6C320A437F21@fugue.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv4-bulk-leasequery-04.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, 23 May 2011 06:11:40 -0000 Not=20sure=20if=20owners=20saying=20matters=20much=20here.=20I=20think=20= we=20are=20ready=20for=20publication. I=20hope=20people=20review=20it=20and=20pass=20on=20their=20comments/sugg= estion=20with=20+1=20or=20-1=20in=20the=20list=20before=2026th. Regards, Bharat ________________________________________ From:=20dhcwg-bounces@ietf.org=20[dhcwg-bounces@ietf.org]=20On=20Behalf= =20Of=20Ted=20Lemon=20[mellon@fugue.com] Sent:=20Wednesday,=20May=2011,=202011=208:36=20PM To:=20dhcwg@ietf.orgWG=20WG Subject:=20[dhcwg]=20WGLC:=20draft-ietf-dhc-dhcpv4-bulk-leasequery-04.txt We=20agreed=20in=20Beijing=20to=20do=20a=20WGLC=20on=20this=20draft,=20bu= t=20it=20never=20happened=20(mea=20culpa).=20=20=20So,=20no=20time=20like= =20the=20present. I'd=20like=20to=20see=20some=20discussion=20and=20review=20of=20the=20dra= ft=97although=20it's=20been=20presented=20in=20several=20meetings,=20ther= e's=20been=20little=20discussion=20on=20the=20list.=20=20=20However,=20ba= sed=20on=20what=20discussion=20and=20review=20has=20occurred=20in=20conte= xt=20of=20in-person=20IETF=20meetings,=20I=20think=20that=20the=20draft= =20is=20ready=20for=20last=20call.=20=20=20So=20please=20review=20the=20d= raft=20and=20submit=20any=20comments=20and=20suggestions=20you=20may=20ha= ve. Also,=20if=20you=20think=20the=20draft=20is=20ready=20for=20publication,= =20please=20say=20so=20on=20the=20mailing=20list.=20=20=20Likewise,=20if= =20you=20think=20it=20is=20not=20ready,=20or=20shouldn't=20be=20published= ,=20please=20say=20so. We=20will=20assess=20consensus=20on=20Thursday,=20May=2026. Thanks! _______________________________________________ dhcwg=20mailing=20list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg ****************=20CAUTION=20-=20Disclaimer=20***************** This=20e-mail=20contains=20PRIVILEGED=20AND=20CONFIDENTIAL=20INFORMATION= =20intended=20solely=20 for=20the=20use=20of=20the=20addressee(s).=20If=20you=20are=20not=20the= =20intended=20recipient,=20please=20 notify=20the=20sender=20by=20e-mail=20and=20delete=20the=20original=20mes= sage.=20Further,=20you=20are=20not=20 to=20copy,=20disclose,=20or=20distribute=20this=20e-mail=20or=20its=20con= tents=20to=20any=20other=20person=20and=20 any=20such=20actions=20are=20unlawful.=20This=20e-mail=20may=20contain=20= viruses.=20Infosys=20has=20taken=20 every=20reasonable=20precaution=20to=20minimize=20this=20risk,=20but=20is= =20not=20liable=20for=20any=20damage=20 you=20may=20sustain=20as=20a=20result=20of=20any=20virus=20in=20this=20e-= mail.=20You=20should=20carry=20out=20your=20 own=20virus=20checks=20before=20opening=20the=20e-mail=20or=20attachment.= =20Infosys=20reserves=20the=20 right=20to=20monitor=20and=20review=20the=20content=20of=20all=20messages= =20sent=20to=20or=20from=20this=20e-mail=20 address.=20Messages=20sent=20to=20or=20from=20this=20e-mail=20address=20m= ay=20be=20stored=20on=20the=20 Infosys=20e-mail=20system. ***INFOSYS********=20End=20of=20Disclaimer=20********INFOSYS*** From mellon@fugue.com Mon May 23 20:22:07 2011 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 F3205E06AA for ; Mon, 23 May 2011 20:22:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0KRRnGuRW6mq for ; Mon, 23 May 2011 20:22:06 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 869DAE0688 for ; Mon, 23 May 2011 20:22:06 -0700 (PDT) Received: from [10.1.10.17] (173-162-214-218-NewEngland.hfc.comcastbusiness.net [173.162.214.218]) by toccata.fugue.com (Postfix) with ESMTPSA id 9AACD34E4507; Mon, 23 May 2011 23:22:39 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1227) Content-Type: text/plain; charset=us-ascii From: Ted Lemon In-Reply-To: <31D55C4D55BEED48A4459EB64567589A115E3C9ED2@BLRKECMBX02.ad.infosys.com> Date: Mon, 23 May 2011 23:22:03 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6088C722-EA75-4454-81AC-721DECE70153@fugue.com> References: <6280FDDC-D655-4FFD-8143-6C320A437F21@fugue.com> <31D55C4D55BEED48A4459EB64567589A115E3C9ED2@BLRKECMBX02.ad.infosys.com> To: Bharat Joshi X-Mailer: Apple Mail (2.1227) Cc: "dhcwg@ietf.orgWG WG" Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv4-bulk-leasequery-04.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, 24 May 2011 03:22:07 -0000 On May 23, 2011, at 2:09 AM, Bharat Joshi wrote: > Not sure if owners saying matters much here. I think we are ready for = publication. It matters, but in order for something to advance through the working = group it would be nice if there were more than one person who wanted it = to advance. So far this is the only response to the WGLC! From mjs@cisco.com Tue May 24 09:36:59 2011 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 D07B6E0730 for ; Tue, 24 May 2011 09:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G1dHRjVxFTTL for ; Tue, 24 May 2011 09:36:59 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by ietfa.amsl.com (Postfix) with ESMTP id E2B9FE0752 for ; Tue, 24 May 2011 09:36:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mjs@cisco.com; l=1043; q=dns/txt; s=iport; t=1306255018; x=1307464618; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=/4dI5XNbv2iEtrujTqU961NLQxK4cdq9j1UdHIyEljI=; b=HQyeG0OxPoFzXczf5RMOLv0AjpF5jiiTz3tsfmweTmVhA2PiwJ4PvwsY Jsmx+C2Rt2PQK62Q3v3IWXRe5dspV/HzorOEOhnXAN1oYD5kdmPcj+y23 6XaVx8vrO41DOJ4way1yo8f75VIlUYEX86LI6fr/Na2KAnkXnwkUOhJPQ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArEHAF3e202tJV2c/2dsb2JhbACYJY4Ed6ttnXeGGwSQH4Q0imk X-IronPort-AV: E=Sophos;i="4.65,261,1304294400"; d="scan'208";a="234529685" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rtp-iport-2.cisco.com with ESMTP; 24 May 2011 16:36:58 +0000 Received: from [161.44.71.239] ([161.44.71.239]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p4OGavkR004621 for ; Tue, 24 May 2011 16:36:57 GMT Message-ID: <4DDBDEA9.6090903@cisco.com> Date: Tue, 24 May 2011 12:36:57 -0400 From: Mark Stapp User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: dhcwg@ietf.org References: <6280FDDC-D655-4FFD-8143-6C320A437F21@fugue.com> In-Reply-To: <6280FDDC-D655-4FFD-8143-6C320A437F21@fugue.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv4-bulk-leasequery-04.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, 24 May 2011 16:36:59 -0000 I think the leasequery draft is ready for publication, and I'd like to see it advance. Regards, Mark On 5/11/11 11:06 AM, Ted Lemon wrote: > We agreed in Beijing to do a WGLC on this draft, but it never happened (mea culpa). So, no time like the present. > > I'd like to see some discussion and review of the draft—although it's been presented in several meetings, there's been little discussion on the list. However, based on what discussion and review has occurred in context of in-person IETF meetings, I think that the draft is ready for last call. So please review the draft and submit any comments and suggestions you may have. > > Also, if you think the draft is ready for publication, please say so on the mailing list. Likewise, if you think it is not ready, or shouldn't be published, please say so. > > We will assess consensus on Thursday, May 26. > > Thanks! > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > From kkinnear@cisco.com Tue May 24 10:31:09 2011 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 1BEFCE06AE for ; Tue, 24 May 2011 10:31:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fFm8FJFYztiJ for ; Tue, 24 May 2011 10:31:08 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 9180BE067F for ; Tue, 24 May 2011 10:31:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=kkinnear@cisco.com; l=1281; q=dns/txt; s=iport; t=1306258268; x=1307467868; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=NgQ/rq6ZQzS0jVhWoy+LIUbKK1sUi+uqQBJB4LYTSUY=; b=lt+0TLEdpkllgAv6Sqs3otmerwTyTkL7OcgsbQKoSCRWuR3HQLEMh7Ov tJu4w5WygR3qIQBBmzUa1mR0oIOVgtyN4Pm35HUci0SvsjORV3N68eviW U+KJmrkmsWRatX+38v8Q7Tl4ADMWBlXQWz3BwCSOCPiqiBHofA2xNI1mJ I=; X-IronPort-AV: E=Sophos;i="4.65,262,1304294400"; d="scan'208";a="702602143" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-6.cisco.com with ESMTP; 24 May 2011 17:31:08 +0000 Received: from [161.44.65.110] ([161.44.65.110]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p4OHV7Po020814; Tue, 24 May 2011 17:31:07 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Kim Kinnear In-Reply-To: <6280FDDC-D655-4FFD-8143-6C320A437F21@fugue.com> Date: Tue, 24 May 2011 13:31:29 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6280FDDC-D655-4FFD-8143-6C320A437F21@fugue.com> To: Ted Lemon X-Mailer: Apple Mail (2.1084) Cc: dhcwg@ietf.org, Kim Kinnear Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv4-bulk-leasequery-04.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, 24 May 2011 17:31:09 -0000 I believe that this draft is ready for publication. I am also one of the authors of this draft, for what that is worth. It is worth noting that this draft represents the convergence of two similar but distinct drafts from two completely different groups of people. Regards -- Kim On May 11, 2011, at 11:06 AM, Ted Lemon wrote: > We agreed in Beijing to do a WGLC on this draft, but it never happened = (mea culpa). So, no time like the present. >=20 > I'd like to see some discussion and review of the draft=97although = it's been presented in several meetings, there's been little discussion = on the list. However, based on what discussion and review has occurred = in context of in-person IETF meetings, I think that the draft is ready = for last call. So please review the draft and submit any comments and = suggestions you may have. >=20 > Also, if you think the draft is ready for publication, please say so = on the mailing list. Likewise, if you think it is not ready, or = shouldn't be published, please say so. >=20 > We will assess consensus on Thursday, May 26. >=20 > Thanks! >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From Ted.Lemon@nominum.com Tue May 24 12:31:25 2011 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 69BF1E07B0 for ; Tue, 24 May 2011 12:31:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.949 X-Spam-Level: X-Spam-Status: No, score=-105.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGjrFzoNkLAv for ; Tue, 24 May 2011 12:31:24 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id 66812E06A5 for ; Tue, 24 May 2011 12:31:24 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKTdwHiytaR+ipPThoevZx0VaYA5hKzW1V@postini.com; Tue, 24 May 2011 12:31:24 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 3C3D3F801C for ; Tue, 24 May 2011 12:31:23 -0700 (PDT) Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 31A9D190052 for ; Tue, 24 May 2011 12:31:23 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from [10.1.10.17] (173.162.214.218) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 24 May 2011 12:31:22 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Apple Message framework v1227) From: Ted Lemon In-Reply-To: Date: Tue, 24 May 2011 15:31:20 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <13399FCA-8A50-40E7-97C4-43545AA53712@nominum.com> References: To: "dhcwg@ietf.org WG" X-Mailer: Apple Mail (2.1227) Subject: Re: [dhcwg] Call for adoption: draft-guo-softwire-6rd-ipv6-config-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: Tue, 24 May 2011 19:31:25 -0000 Reminder: the call for adoption on this draft expires tomorrow. Thus = far there seems to be adequate support for adopting the work, and no = objections. If you wish to weigh in on the question, please do so = today. Thanks! From marc.blanchet@viagenie.ca Tue May 24 12:35:50 2011 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 395C2E0754 for ; Tue, 24 May 2011 12:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.201 X-Spam-Level: X-Spam-Status: No, score=-102.201 tagged_above=-999 required=5 tests=[AWL=0.399, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ndk9vWBxtg7g for ; Tue, 24 May 2011 12:35:47 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 33F4BE06A5 for ; Tue, 24 May 2011 12:35:47 -0700 (PDT) Received: from mbl.local (unknown [IPv6:2607:fa48:6e44:d060:5ab0:35ff:fe6a:294a]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 09DB121C77 for ; Tue, 24 May 2011 15:35:45 -0400 (EDT) Message-ID: <4DDC0891.4020607@viagenie.ca> Date: Tue, 24 May 2011 15:35:45 -0400 From: Marc Blanchet User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; fr; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: dhcwg@ietf.org References: <13399FCA-8A50-40E7-97C4-43545AA53712@nominum.com> In-Reply-To: <13399FCA-8A50-40E7-97C4-43545AA53712@nominum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [dhcwg] Call for adoption: draft-guo-softwire-6rd-ipv6-config-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: Tue, 24 May 2011 19:35:50 -0000 have a question: this draft talks about 6rd. but my reading is that this issue is more generic than 6rd, isn't it? Should that be written in a more generic way (i.e. a dhcpv6 client that can't use its link-local address as source for some types of links, including 6rd)? Marc. Le 11-05-24 15:31, Ted Lemon a écrit : > Reminder: the call for adoption on this draft expires tomorrow. Thus far there seems to be adequate support for adopting the work, and no objections. If you wish to weigh in on the question, please do so today. > > Thanks! > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg -- ========= IETF81 Quebec city: http://ietf81.ca IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca DTN Implementation: http://postellation.viagenie.ca NAT64-DNS64 Opensource: http://ecdysis.viagenie.ca Space Assigned Number Authority: http://sanaregistry.org From tdonahue@cisco.com Tue May 24 12:38:35 2011 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 4A7B6E06AE for ; Tue, 24 May 2011 12:38:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nVyXQ+bSVtXj for ; Tue, 24 May 2011 12:38:34 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id CC373E06A5 for ; Tue, 24 May 2011 12:38:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tdonahue@cisco.com; l=82; q=dns/txt; s=iport; t=1306265914; x=1307475514; h=from:mime-version:content-transfer-encoding:message-id: date:to:subject; bh=NbJ/KWzov62Fnn0b4REl8v02Xh5/HksFGyFQ5heaI9k=; b=P+WuukCc+QMmdMydUjWYhy4yMnXK+xVwSLM4uu1jf2ILf4Ovr8Ep5/tS 3XqUKDIGMUlPt9wI54IM2qp8uCcRhT/lgebu5TkC4cTAiyq0CLZCNTKKU hv41Ibs5zurHFTK78GK4vdQgw3TNGV0KNS5Zax7zMYLkkKFVvHcmIyDW9 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtwGAAII3E2rRDoJ/2dsb2JhbACYJY4Ed4hpoT6BHZ1zhhsEkB+PHQ X-IronPort-AV: E=Sophos;i="4.65,262,1304294400"; d="scan'208";a="453560963" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-1.cisco.com with ESMTP; 24 May 2011 19:38:34 +0000 Received: from bxb-lds-057.cisco.com (bxb-lds-057.cisco.com [161.44.95.77]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p4OJcYMS026490 for ; Tue, 24 May 2011 19:38:34 GMT Received: from bxb-lds-057.cisco.com (localhost [127.0.0.1]) by bxb-lds-057.cisco.com (8.13.1/8.13.1) with ESMTP id p4OJcXfY024659 for ; Tue, 24 May 2011 15:38:33 -0400 Received: (from tdonahue@localhost) by bxb-lds-057.cisco.com (8.13.1/8.13.1/Submit) id p4OJcXFk024651; Tue, 24 May 2011 15:38:33 -0400 From: Tim Donahue MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19932.2361.497201.927195@gargle.gargle.HOWL> Date: Tue, 24 May 2011 15:38:33 -0400 To: dhcwg@ietf.org X-Mailer: VM 8.1.1 under 22.3.1 (i686-pc-linux-gnu) Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv4-bulk-leasequery-04.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, 24 May 2011 19:42:13 -0000 I believe this draft is ready for publication. Thanks, regards Tim Donahue From volz@cisco.com Tue May 24 13:08:11 2011 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 6DAB7E07AC for ; Tue, 24 May 2011 13:08:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.424 X-Spam-Level: X-Spam-Status: No, score=-10.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eNgocZC18xbM for ; Tue, 24 May 2011 13:08:10 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id EA2ACE0784 for ; Tue, 24 May 2011 13:08:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=860; q=dns/txt; s=iport; t=1306267690; x=1307477290; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=rE+LhedoC6Z/eotnqbfjPBvw6G6G3ogRSjz9H6tOpgg=; b=hetzH6/WXUWqxePgAx8pixn8N+xgeH2DqsqsR+4Ql/g3Vs765GEp0q4n oODIq/UHXbMy0TdtIptV11zdzNOgTGHgs5yxesGhike+X09QGvmicY3au ob3jWTmHwpzoaV/gZhxWxkYFvAJ8KK4d9zgdFq1wEy4g1L7Wb5yvu0fog E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjwBABUP3E2tJXG//2dsb2JhbACXZY5Ed6sxnXCGGwSGVo4GimI X-IronPort-AV: E=Sophos;i="4.65,263,1304294400"; d="scan'208";a="322723217" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by sj-iport-3.cisco.com with ESMTP; 24 May 2011 20:08:10 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id p4OK8ArM020825; Tue, 24 May 2011 20:08:10 GMT Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 24 May 2011 15:08:09 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 May 2011 15:08:08 -0500 Message-ID: In-Reply-To: <6088C722-EA75-4454-81AC-721DECE70153@fugue.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-dhcpv4-bulk-leasequery-04.txt Thread-Index: AcwZwcnoO6ox9PtaSrOceokuYw4kGQAjFTmA References: <6280FDDC-D655-4FFD-8143-6C320A437F21@fugue.com><31D55C4D55BEED48A4459EB64567589A115E3C9ED2@BLRKECMBX02.ad.infosys.com> <6088C722-EA75-4454-81AC-721DECE70153@fugue.com> From: "Bernie Volz (volz)" To: "Ted Lemon" , "Bharat Joshi" X-OriginalArrivalTime: 24 May 2011 20:08:09.0409 (UTC) FILETIME=[4D550310:01CC1A4E] Cc: dhcwg@ietf.org Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv4-bulk-leasequery-04.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, 24 May 2011 20:08:11 -0000 I, as a contributor to this work, believe this document is ready and would like to see it advance. - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Ted Lemon Sent: Monday, May 23, 2011 11:22 PM To: Bharat Joshi Cc: dhcwg@ietf.orgWG WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv4-bulk-leasequery-04.txt On May 23, 2011, at 2:09 AM, Bharat Joshi wrote: > Not sure if owners saying matters much here. I think we are ready for publication. It matters, but in order for something to advance through the working group it would be nice if there were more than one person who wanted it to advance. So far this is the only response to the WGLC! _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From Ted.Lemon@nominum.com Tue May 24 13:38:54 2011 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 5702FE073C for ; Tue, 24 May 2011 13:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.079 X-Spam-Level: X-Spam-Status: No, score=-106.079 tagged_above=-999 required=5 tests=[AWL=0.520, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZ2XS0RVCx05 for ; Tue, 24 May 2011 13:38:53 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 45A53E0670 for ; Tue, 24 May 2011 13:38:52 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKTdwXXIZi60a6j/3NqwBIYSICHhLCI/BD@postini.com; Tue, 24 May 2011 13:38: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 2F90B1B856A for ; Tue, 24 May 2011 13:38:52 -0700 (PDT) Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 23BC3190052; Tue, 24 May 2011 13:38:52 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from [10.1.10.17] (173.162.214.218) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 24 May 2011 13:38:51 -0700 MIME-Version: 1.0 (Apple Message framework v1227) Content-Type: text/plain; charset="us-ascii" From: Ted Lemon In-Reply-To: <4DDC0891.4020607@viagenie.ca> Date: Tue, 24 May 2011 16:38:49 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <38A979D4-4B2C-4D9C-ADF2-2C0A748B1C9A@nominum.com> References: <13399FCA-8A50-40E7-97C4-43545AA53712@nominum.com> <4DDC0891.4020607@viagenie.ca> To: Marc Blanchet X-Mailer: Apple Mail (2.1227) Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Call for adoption: draft-guo-softwire-6rd-ipv6-config-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: Tue, 24 May 2011 20:38:54 -0000 On May 24, 2011, at 3:35 PM, Marc Blanchet wrote: > have a question: this draft talks about 6rd. but my reading is that = this issue is more generic than 6rd, isn't it? Should that be written in = a more generic way (i.e. a dhcpv6 client that can't use its link-local = address as source for some types of links, including 6rd)? My expectation is that whatever mechanism we come up with will be = general; 6rd is the motivation for doing the work right now, not the = only possible use for the work. Your participation in making sure that = the work is properly scoped would be greatly appreciated. :) From Ted.Lemon@nominum.com Wed May 25 09:16:48 2011 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 71D63E080F for ; Wed, 25 May 2011 09:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.228 X-Spam-Level: X-Spam-Status: No, score=-106.228 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S7GVSVYi3jBe for ; Wed, 25 May 2011 09:16:48 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id 943C9E07F3 for ; Wed, 25 May 2011 09:16:47 -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 DSNKTd0rbnFU/zbVDHQabsKhwm/CJT43wNV6@postini.com; Wed, 25 May 2011 09:16:47 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 A8525F80A6 for ; Wed, 25 May 2011 09:16:46 -0700 (PDT) Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 9C94A190058 for ; Wed, 25 May 2011 09:16:46 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from [10.1.10.12] (173.162.214.218) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 25 May 2011 09:16:46 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Apple Message framework v1227) From: Ted Lemon In-Reply-To: Date: Wed, 25 May 2011 12:16:44 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: To: "dhcwg@ietf.org WG" X-Mailer: Apple Mail (2.1227) Subject: Re: [dhcwg] Call for adoption: draft-guo-softwire-6rd-ipv6-config-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, 25 May 2011 16:16:48 -0000 On May 10, 2011, at 10:58 PM, Ted Lemon wrote: > If you agree that the working group should do this work, please = indicate that agreement on the list; likewise if you disagree. If you = have no opinion, there is no need to say so. >=20 > We will evaluate the consensus on Wednesday, May 25. Please get your = comments in before that time. The consensus seems to be that this work is worth doing, although there = was some discussion about the scope of the work. I think the authors = should consider working with Marc Blanchet to get the document scoped = correctly, and possibly bring him on as a co-author. In any case, the = working group has adopted this as a working group item, so the authors = should submit a draft-ietf-... draft. BTW, if the authors agree to expand the scope, I would suggest calling = the draft something like "DHCPv6 through Tunnels" and = draft-ietf-dhc-dhcpv6-tunnels-00.txt instead of keeping 6rd in the name. From marc.blanchet@viagenie.ca Wed May 25 10:07:58 2011 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 870BF130035 for ; Wed, 25 May 2011 10:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.4 X-Spam-Level: X-Spam-Status: No, score=-102.4 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l4vaKGUiP7iu for ; Wed, 25 May 2011 10:07:57 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 6D755130032 for ; Wed, 25 May 2011 10:07:57 -0700 (PDT) Received: from h109.viagenie.ca (unknown [IPv6:2620:0:230:c000:5ab0:35ff:fef4:6fa]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 779BF21F5B for ; Wed, 25 May 2011 13:07:55 -0400 (EDT) Message-ID: <4DDD376B.9040307@viagenie.ca> Date: Wed, 25 May 2011 13:07:55 -0400 From: Marc Blanchet User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; fr; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: dhcwg@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [dhcwg] Call for adoption: draft-guo-softwire-6rd-ipv6-config-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, 25 May 2011 17:07:58 -0000 Le 11-05-25 12:16, Ted Lemon a écrit : > On May 10, 2011, at 10:58 PM, Ted Lemon wrote: >> If you agree that the working group should do this work, please indicate that agreement on the list; likewise if you disagree. If you have no opinion, there is no need to say so. >> >> We will evaluate the consensus on Wednesday, May 25. Please get your comments in before that time. > > The consensus seems to be that this work is worth doing, although there was some discussion about the scope of the work. I think the authors should consider working with Marc Blanchet to get the document scoped correctly, and possibly bring him on as a co-author. In any case, the working group has adopted this as a working group item, so the authors should submit a draft-ietf-... draft. > > BTW, if the authors agree to expand the scope, I would suggest calling the draft something like "DHCPv6 through Tunnels" and draft-ietf-dhc-dhcpv6-tunnels-00.txt instead of keeping 6rd in the name. > I would even make it more like "DHCPv6 through non-capable LL links" (well, not good, but will have to figure that out). Marc. > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg -- ========= IETF81 Quebec city: http://ietf81.ca IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca DTN Implementation: http://postellation.viagenie.ca NAT64-DNS64 Opensource: http://ecdysis.viagenie.ca Space Assigned Number Authority: http://sanaregistry.org From xuxh@huawei.com Wed May 25 18:03:07 2011 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 607ECE06AB for ; Wed, 25 May 2011 18:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.226 X-Spam-Level: X-Spam-Status: No, score=-3.226 tagged_above=-999 required=5 tests=[AWL=0.583, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MD8FuBCGzuaV for ; Wed, 25 May 2011 18:03:06 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 9DFBCE06A3 for ; Wed, 25 May 2011 18:03:06 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLS003GB2TO81@szxga04-in.huawei.com> for dhcwg@ietf.org; Thu, 26 May 2011 09:01:00 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLS00LZZ2TOWT@szxga04-in.huawei.com> for dhcwg@ietf.org; Thu, 26 May 2011 09:01:00 +0800 (CST) Received: from x41208c ([10.110.98.38]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LLS00M7L2TNUC@szxml06-in.huawei.com> for dhcwg@ietf.org; Thu, 26 May 2011 09:01:00 +0800 (CST) Date: Thu, 26 May 2011 09:10:38 +0800 From: Xu Xiaohu In-reply-to: To: 'Ted Lemon' , dhcwg@ietf.org Message-id: <001a01cc1b41$b99ab5d0$2cd02170$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=gb2312 Content-language: zh-cn Content-transfer-encoding: quoted-printable Thread-index: Acwa93bX6KNrWbR0Ry+ENPeReJtDYgASYrew References: Subject: Re: [dhcwg] Call for adoption: draft-guo-softwire-6rd-ipv6-config-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: Thu, 26 May 2011 01:03:07 -0000 Hi Ted, > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: dhcwg-bounces@ietf.org = [mailto:dhcwg-bounces@ietf.org] =B4=FA=B1=ED Ted > Lemon > =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA5=D4=C226=C8=D5 0:17 > =CA=D5=BC=FE=C8=CB: dhcwg@ietf.org WG > =D6=F7=CC=E2: Re: [dhcwg] Call for adoption: draft-guo-softwire-6rd-ipv6-config-02.txt >=20 > On May 10, 2011, at 10:58 PM, Ted Lemon wrote: > > If you agree that the working group should do this work, please = indicate that > agreement on the list; likewise if you disagree. If you have no = opinion, there > is no need to say so. > > > > We will evaluate the consensus on Wednesday, May 25. Please get = your > comments in before that time. >=20 > The consensus seems to be that this work is worth doing, although = there was > some discussion about the scope of the work. I think the authors = should > consider working with Marc Blanchet to get the document scoped = correctly, > and possibly bring him on as a co-author. In any case, the working = group has > adopted this as a working group item, so the authors should submit a > draft-ietf-... draft. Fully agree. Welcome Marc to work with us to get the document scoped correctly. > BTW, if the authors agree to expand the scope, I would suggest calling = the > draft something like "DHCPv6 through Tunnels" and > draft-ietf-dhc-dhcpv6-tunnels-00.txt instead of keeping 6rd in the = name. It's a good point. Best regards, Xiaohu > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From xuxh@huawei.com Wed May 25 18:14:31 2011 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 5E9CBE06A3 for ; Wed, 25 May 2011 18:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.372 X-Spam-Level: X-Spam-Status: No, score=-3.372 tagged_above=-999 required=5 tests=[AWL=0.438, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OTFFV2v5gGda for ; Wed, 25 May 2011 18:14:30 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 248F4E0690 for ; Wed, 25 May 2011 18:14:30 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLS0031B3G161@szxga04-in.huawei.com> for dhcwg@ietf.org; Thu, 26 May 2011 09:14:26 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLS004003G14O@szxga04-in.huawei.com> for dhcwg@ietf.org; Thu, 26 May 2011 09:14:25 +0800 (CST) Received: from x41208c ([10.110.98.38]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LLS00HQY3G19X@szxml04-in.huawei.com> for dhcwg@ietf.org; Thu, 26 May 2011 09:14:25 +0800 (CST) Date: Thu, 26 May 2011 09:24:03 +0800 From: Xu Xiaohu In-reply-to: <4DDD376B.9040307@viagenie.ca> To: 'Marc Blanchet' , dhcwg@ietf.org Message-id: <001b01cc1b43$99b5f7a0$cd21e6e0$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=gb2312 Content-language: zh-cn Content-transfer-encoding: quoted-printable Thread-index: Acwa/mN8IKoa5UkxT0OuouTWRuPBLAAQ/Z3g References: <4DDD376B.9040307@viagenie.ca> Subject: Re: [dhcwg] Call for adoption: draft-guo-softwire-6rd-ipv6-config-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: Thu, 26 May 2011 01:14:31 -0000 > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: dhcwg-bounces@ietf.org = [mailto:dhcwg-bounces@ietf.org] =B4=FA=B1=ED > Marc Blanchet > =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA5=D4=C226=C8=D5 1:08 > =CA=D5=BC=FE=C8=CB: dhcwg@ietf.org > =D6=F7=CC=E2: Re: [dhcwg] Call for adoption: draft-guo-softwire-6rd-ipv6-config-02.txt >=20 > Le 11-05-25 12:16, Ted Lemon a =A8=A6crit : > > On May 10, 2011, at 10:58 PM, Ted Lemon wrote: > >> If you agree that the working group should do this work, please indicate that > agreement on the list; likewise if you disagree. If you have no = opinion, there > is no need to say so. > >> > >> We will evaluate the consensus on Wednesday, May 25. Please get = your > comments in before that time. > > > > The consensus seems to be that this work is worth doing, although = there was > some discussion about the scope of the work. I think the authors = should > consider working with Marc Blanchet to get the document scoped = correctly, > and possibly bring him on as a co-author. In any case, the working = group has > adopted this as a working group item, so the authors should submit a > draft-ietf-... draft. > > > > BTW, if the authors agree to expand the scope, I would suggest = calling the > draft something like "DHCPv6 through Tunnels" and > draft-ietf-dhc-dhcpv6-tunnels-00.txt instead of keeping 6rd in the = name. > > >=20 > I would even make it more like "DHCPv6 through non-capable LL links" > (well, not good, but will have to figure that out). How about " DHCPv6 through Tunnels incapable of Carrying Link-Local Addresses" Best regards, Xiaohu > Marc. >=20 > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www.ietf.org/mailman/listinfo/dhcwg >=20 >=20 > -- > =3D=3D=3D=3D=3D=3D=3D=3D=3D > IETF81 Quebec city: http://ietf81.ca > IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca > Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca > DTN Implementation: http://postellation.viagenie.ca > NAT64-DNS64 Opensource: http://ecdysis.viagenie.ca > Space Assigned Number Authority: http://sanaregistry.org > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From RAMAKRISHNADTV@infosys.com Thu May 26 06:14:24 2011 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 ACD3A130028 for ; Thu, 26 May 2011 06:14:24 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wv9wDvbUorYd for ; Thu, 26 May 2011 06:14:24 -0700 (PDT) Received: from KECGATE03.infosys.com (kecgate03.infosys.com [122.98.10.31]) by ietfa.amsl.com (Postfix) with ESMTP id 682F913001C for ; Thu, 26 May 2011 06:14:23 -0700 (PDT) X-TM-IMSS-Message-ID: <10c8e7fe0002896e@infosys.com> Received: from blrkechub02.ad.infosys.com ([10.66.236.42]) by infosys.com ([122.98.10.31]) with ESMTP (TREND IMSS SMTP Service 7.1) id 10c8e7fe0002896e ; Thu, 26 May 2011 18:36:09 +0530 Received: from BLRKECMBX03.ad.infosys.com ([10.66.236.23]) by blrkechub02.ad.infosys.com ([10.66.236.42]) with mapi; Thu, 26 May 2011 18:44:20 +0530 From: RAMAKRISHNADTV To: Ted Lemon Date: Thu, 26 May 2011 18:42:28 +0530 Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-dhcpv4-bulk-leasequery-04.txt Thread-Index: AcwZwcnoO6ox9PtaSrOceokuYw4kGQAjFTmAAFYcWfE= Message-ID: <5FDD79D8731F4A4B87487A5A85327B821809DB7B37@BLRKECMBX03.ad.infosys.com> References: <6280FDDC-D655-4FFD-8143-6C320A437F21@fugue.com><31D55C4D55BEED48A4459EB64567589A115E3C9ED2@BLRKECMBX02.ad.infosys.com> <6088C722-EA75-4454-81AC-721DECE70153@fugue.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv4-bulk-leasequery-04.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: Thu, 26 May 2011 13:14:24 -0000 I,=20as=20a=20co-author=20of=20this=20draft,=20believe=20this=20document= =20is=20ready=20and would=20like=20to=20see=20it=20advance. Regards, Ramakrishna=20DTV. ________________________________________ From:=20dhcwg-bounces@ietf.org=20[dhcwg-bounces@ietf.org]=20On=20Behalf= =20Of=20Bernie=20Volz=20(volz)=20[volz@cisco.com] Sent:=20Wednesday,=20May=2025,=202011=201:38=20AM To:=20Ted=20Lemon;=20Bharat=20Joshi Cc:=20dhcwg@ietf.org Subject:=20Re:=20[dhcwg]=20WGLC:=20draft-ietf-dhc-dhcpv4-bulk-leasequery-= 04.txt I,=20as=20a=20contributor=20to=20this=20work,=20believe=20this=20document= =20is=20ready=20and would=20like=20to=20see=20it=20advance. -=20Bernie -----Original=20Message----- From:=20dhcwg-bounces@ietf.org=20[mailto:dhcwg-bounces@ietf.org]=20On=20B= ehalf Of=20Ted=20Lemon Sent:=20Monday,=20May=2023,=202011=2011:22=20PM To:=20Bharat=20Joshi Cc:=20dhcwg@ietf.orgWG=20WG Subject:=20Re:=20[dhcwg]=20WGLC:=20draft-ietf-dhc-dhcpv4-bulk-leasequery-= 04.txt On=20May=2023,=202011,=20at=202:09=20AM,=20Bharat=20Joshi=20wrote: >=20Not=20sure=20if=20owners=20saying=20matters=20much=20here.=20I=20thin= k=20we=20are=20ready=20for publication. It=20matters,=20but=20in=20order=20for=20something=20to=20advance=20throu= gh=20the=20working group=20it=20would=20be=20nice=20if=20there=20were=20more=20than=20one=20= person=20who=20wanted=20it to=20advance.=20=20=20So=20far=20this=20is=20the=20only=20response=20to= =20the=20WGLC! _______________________________________________ dhcwg=20mailing=20list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg=20mailing=20list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg ****************=20CAUTION=20-=20Disclaimer=20***************** This=20e-mail=20contains=20PRIVILEGED=20AND=20CONFIDENTIAL=20INFORMATION= =20intended=20solely=20 for=20the=20use=20of=20the=20addressee(s).=20If=20you=20are=20not=20the= =20intended=20recipient,=20please=20 notify=20the=20sender=20by=20e-mail=20and=20delete=20the=20original=20mes= sage.=20Further,=20you=20are=20not=20 to=20copy,=20disclose,=20or=20distribute=20this=20e-mail=20or=20its=20con= tents=20to=20any=20other=20person=20and=20 any=20such=20actions=20are=20unlawful.=20This=20e-mail=20may=20contain=20= viruses.=20Infosys=20has=20taken=20 every=20reasonable=20precaution=20to=20minimize=20this=20risk,=20but=20is= =20not=20liable=20for=20any=20damage=20 you=20may=20sustain=20as=20a=20result=20of=20any=20virus=20in=20this=20e-= mail.=20You=20should=20carry=20out=20your=20 own=20virus=20checks=20before=20opening=20the=20e-mail=20or=20attachment.= =20Infosys=20reserves=20the=20 right=20to=20monitor=20and=20review=20the=20content=20of=20all=20messages= =20sent=20to=20or=20from=20this=20e-mail=20 address.=20Messages=20sent=20to=20or=20from=20this=20e-mail=20address=20m= ay=20be=20stored=20on=20the=20 Infosys=20e-mail=20system. ***INFOSYS********=20End=20of=20Disclaimer=20********INFOSYS*** From Ted.Lemon@nominum.com Thu May 26 07:13:59 2011 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 6AB7CE06B2 for ; Thu, 26 May 2011 07:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.339 X-Spam-Level: X-Spam-Status: No, score=-106.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBE-09t8XVUh for ; Thu, 26 May 2011 07:13:58 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id AD009E0678 for ; Thu, 26 May 2011 07:13:58 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKTd5gHCTDE6ulXLL/clZ+OpEgWXkwaqv4@postini.com; Thu, 26 May 2011 07:13:58 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 9AB63F80DE for ; Thu, 26 May 2011 07:13:41 -0700 (PDT) Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 92BEA190058; Thu, 26 May 2011 07:13:41 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from [10.1.10.12] (173.162.214.218) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 26 May 2011 07:13:41 -0700 MIME-Version: 1.0 (Apple Message framework v1227) Content-Type: text/plain; charset="iso-8859-1" From: Ted Lemon In-Reply-To: <001b01cc1b43$99b5f7a0$cd21e6e0$@com> Date: Thu, 26 May 2011 10:13:39 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <4E43A7B6-1D2D-41BB-8D8B-D550969ACFDF@nominum.com> References: <4DDD376B.9040307@viagenie.ca> <001b01cc1b43$99b5f7a0$cd21e6e0$@com> To: Xu Xiaohu X-Mailer: Apple Mail (2.1227) Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Call for adoption: draft-guo-softwire-6rd-ipv6-config-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: Thu, 26 May 2011 14:13:59 -0000 Le May 25, 2011 =E0 9:24 PM, Xu Xiaohu a =E9crit : > DHCPv6 through Tunnels incapable of Carrying Link-Local > Addresses Kind of long. Naive question: are there tunnels that can carry = link-local addresses? From Ted.Lemon@nominum.com Thu May 26 07:14:43 2011 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 62B33E071E for ; Thu, 26 May 2011 07:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.363 X-Spam-Level: X-Spam-Status: No, score=-106.363 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a+eCHPbJVfMD for ; Thu, 26 May 2011 07:14:42 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id A2417E0678 for ; Thu, 26 May 2011 07:14:42 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKTd5gUtot85JDSpfpdzpzCVmIcRnQfK1k@postini.com; Thu, 26 May 2011 07:14:42 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 D90F1F80DE for ; Thu, 26 May 2011 07:14:41 -0700 (PDT) Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id D2572190058 for ; Thu, 26 May 2011 07:14:41 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from [10.1.10.12] (173.162.214.218) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 26 May 2011 07:14:41 -0700 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Apple Message framework v1227) From: Ted Lemon In-Reply-To: <6280FDDC-D655-4FFD-8143-6C320A437F21@fugue.com> Date: Thu, 26 May 2011 10:14:41 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <6280FDDC-D655-4FFD-8143-6C320A437F21@fugue.com> To: "dhcwg@ietf.orgWG WG" X-Mailer: Apple Mail (2.1227) Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv4-bulk-leasequery-04.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: Thu, 26 May 2011 14:14:43 -0000 Le May 11, 2011 =E0 11:06 AM, Ted Lemon a =E9crit : > We will assess consensus on Thursday, May 26. There appears to be substantial support for this draft, and no dissent, = so it passes last call. From marc.blanchet@viagenie.ca Thu May 26 07:34:26 2011 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 38852E06B2 for ; Thu, 26 May 2011 07:34:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.466 X-Spam-Level: X-Spam-Status: No, score=-102.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ywb9lP+-Y3G for ; Thu, 26 May 2011 07:34:14 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 84446E0657 for ; Thu, 26 May 2011 07:34:13 -0700 (PDT) Received: from mbl.local (modemcable006.77-176-173.mc.videotron.ca [173.176.77.6]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 07BBD21157; Thu, 26 May 2011 10:34:09 -0400 (EDT) Message-ID: <4DDE64E1.60707@viagenie.ca> Date: Thu, 26 May 2011 10:34:09 -0400 From: Marc Blanchet User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; fr; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Ted Lemon References: <4DDD376B.9040307@viagenie.ca> <001b01cc1b43$99b5f7a0$cd21e6e0$@com> <4E43A7B6-1D2D-41BB-8D8B-D550969ACFDF@nominum.com> In-Reply-To: <4E43A7B6-1D2D-41BB-8D8B-D550969ACFDF@nominum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Call for adoption: draft-guo-softwire-6rd-ipv6-config-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: Thu, 26 May 2011 14:34:26 -0000 Le 11-05-26 10:13, Ted Lemon a écrit : > Le May 25, 2011 à 9:24 PM, Xu Xiaohu a écrit : >> DHCPv6 through Tunnels incapable of Carrying Link-Local >> Addresses > > Kind of long. Naive question: are there tunnels that can carry link-local addresses? well that was around my initial thoughts: we need to define the spec to cover all links that have the same properties as 6rd (tunnel or not) and then show 6rd as the example. Marc. -- ========= IETF81 Quebec city: http://ietf81.ca IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca DTN Implementation: http://postellation.viagenie.ca NAT64-DNS64 Opensource: http://ecdysis.viagenie.ca Space Assigned Number Authority: http://sanaregistry.org From Ted.Lemon@nominum.com Thu May 26 18:05:26 2011 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 B6E1DE06F0 for ; Thu, 26 May 2011 18:05:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.499 X-Spam-Level: X-Spam-Status: No, score=-106.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s7sOsHhGtccN for ; Thu, 26 May 2011 18:05:26 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by ietfa.amsl.com (Postfix) with ESMTP id F1762E06A5 for ; Thu, 26 May 2011 18:05:25 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKTd741VgTSChxWVsLEJsTmQQ58hulzu1k@postini.com; Thu, 26 May 2011 18:05:26 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 D54C91B8596 for ; Thu, 26 May 2011 18:05:24 -0700 (PDT) Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id C6465190058; Thu, 26 May 2011 18:05:24 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from vpna-148.vpn.nominum.com (64.89.227.148) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 26 May 2011 18:05:24 -0700 MIME-Version: 1.0 (Apple Message framework v1227) Content-Type: text/plain; charset="iso-8859-1" From: Ted Lemon In-Reply-To: <4DDE64E1.60707@viagenie.ca> Date: Thu, 26 May 2011 21:05:23 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <2B8B4573-07B2-4421-B4DC-086D2F969962@nominum.com> References: <4DDD376B.9040307@viagenie.ca> <001b01cc1b43$99b5f7a0$cd21e6e0$@com> <4E43A7B6-1D2D-41BB-8D8B-D550969ACFDF@nominum.com> <4DDE64E1.60707@viagenie.ca> To: Marc Blanchet X-Mailer: Apple Mail (2.1227) Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Call for adoption: draft-guo-softwire-6rd-ipv6-config-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: Fri, 27 May 2011 01:05:26 -0000 Le May 26, 2011 =E0 10:34 AM, Marc Blanchet a =E9crit : > well that was around my initial thoughts: we need to define the spec = to cover all links that have the same properties as 6rd (tunnel or not) = and then show 6rd as the example. Be careful: if you try to broaden the scope so far that it changes the = solution, make sure that the problem that you're using to justify = broadening the scope is a real problem, and not a theoretical problem. From xuxh@huawei.com Fri May 27 03:05:15 2011 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 D6770E06CE for ; Fri, 27 May 2011 03:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.037 X-Spam-Level: X-Spam-Status: No, score=-1.037 tagged_above=-999 required=5 tests=[AWL=-2.072, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hKezUB5aNMWw for ; Fri, 27 May 2011 03:05:15 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD25E06BE for ; Fri, 27 May 2011 03:05:15 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLU00717MMKWZ@szxga04-in.huawei.com> for dhcwg@ietf.org; Fri, 27 May 2011 18:03:56 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLU00BVHMMK3U@szxga04-in.huawei.com> for dhcwg@ietf.org; Fri, 27 May 2011 18:03:56 +0800 (CST) Received: from x41208c ([10.110.98.38]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LLU00EVAMMJHX@szxml06-in.huawei.com> for dhcwg@ietf.org; Fri, 27 May 2011 18:03:56 +0800 (CST) Date: Fri, 27 May 2011 18:13:35 +0800 From: Xu Xiaohu In-reply-to: <4E43A7B6-1D2D-41BB-8D8B-D550969ACFDF@nominum.com> To: 'Ted Lemon' Message-id: <001001cc1c56$bda7d5c0$38f78140$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=gb2312 Content-language: zh-cn Content-transfer-encoding: quoted-printable Thread-index: AcwbryyyaYtgq3C+SNugMzKp4dKS7QAp1kVQ References: <4DDD376B.9040307@viagenie.ca> <001b01cc1b43$99b5f7a0$cd21e6e0$@com> <4E43A7B6-1D2D-41BB-8D8B-D550969ACFDF@nominum.com> Cc: dhcwg@ietf.org Subject: [dhcwg] =?gb2312?b?tPC4tDogIENhbGwJZm9yCWFkb3B0aW9uOglkcmFmdC1n?= =?gb2312?b?dW8tc29mdHdpcmUtNnJkLWlwdjYtY29uZmlnLTAyLnR4dA==?= 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, 27 May 2011 10:05:15 -0000 Hi Ted,=20 Your observation is right. We will take " DHCPv6 through Tunnels " as = the draft title. Best regards, Xiaohu > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: Ted Lemon [mailto:Ted.Lemon@nominum.com] > =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA5=D4=C226=C8=D5 22:14 > =CA=D5=BC=FE=C8=CB: Xu Xiaohu > =B3=AD=CB=CD: 'Marc Blanchet'; dhcwg@ietf.org > =D6=F7=CC=E2: Re: [dhcwg] Call for adoption: draft-guo-softwire-6rd-ipv6-config-02.txt >=20 > Le May 25, 2011 =A8=A4 9:24 PM, Xu Xiaohu a =A8=A6crit : > > DHCPv6 through Tunnels incapable of Carrying Link-Local > > Addresses >=20 > Kind of long. Naive question: are there tunnels that can carry link-local > addresses? From leaf.y.yeh@huawei.com Tue May 31 06:46:16 2011 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 24280E0877 for ; Tue, 31 May 2011 06:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.799 X-Spam-Level: X-Spam-Status: No, score=-5.799 tagged_above=-999 required=5 tests=[AWL=0.799, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aVcGDWZ5EPk6 for ; Tue, 31 May 2011 06:46:14 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 544D2E071F for ; Tue, 31 May 2011 06:46:14 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LM200HB0BJFUY@szxga03-in.huawei.com> for dhcwg@ietf.org; Tue, 31 May 2011 21:45:15 +0800 (CST) Received: from szxeml206-edg.china.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LM2003WIBJF0J@szxga03-in.huawei.com> for dhcwg@ietf.org; Tue, 31 May 2011 21:45:15 +0800 (CST) Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 31 May 2011 21:45:12 +0800 Received: from SZXEML514-MBX.china.huawei.com ([169.254.2.14]) by szxeml411-hub.china.huawei.com ([169.254.8.131]) with mapi id 14.01.0270.001; Tue, 31 May 2011 21:45:13 +0800 Date: Tue, 31 May 2011 13:45:12 +0000 From: Leaf yeh X-Originating-IP: [172.24.2.40] To: Ted Lemon , "dhcwg@ietf.org WG" Message-id: <9CEBD6CD-7411-4562-825A-B80D01878789@mimectl> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_6xeyVF2Wt/dxjcd3936xlQ)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: Question of Clarification: draft-ietf-dhc-dhcpv6-relay-supplied-options-06 Thread-index: AcwfmPrGMmZvTr+XSHWeIauyRQmfug== X-MS-Has-Attach: X-MS-TNEF-Correlator: Subject: [dhcwg] Question of Clarification: draft-ietf-dhc-dhcpv6-relay-supplied-options-06 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, 31 May 2011 13:46:16 -0000 --Boundary_(ID_6xeyVF2Wt/dxjcd3936xlQ) Content-type: text/plain; charset=iso-2022-jp Content-transfer-encoding: 7BIT Hi Ted, Not sure the following comments are too late and will be helpful. l Questions of clarification: 1. Section 6 - DHCP servers normally construct a list of options that are candidates to send to the DHCP client, and then construct the DHCP packet according to section 17.2.2 of DHCPv6 [RFC3315]. Not sure about that the reply message sent by the Server is Advertise (2) per 17.2.2 of RFC3315. I guess the wording might be '...construct the DHCP packet according to section 20.3 of DHCPv6 [RFC3315]. ' The message sent by the server should also include the relay-reply (13) of Reply (7). l Suggestion on the wording revisions for the convenient reference: 1. Section 5 - Relay agents MAY include a Relay-Supplied Options option in the option payload of a Relay-Forward message. Suggested wording: Relay agents MAY include a Relay-Supplied Options option in a Relay-Forward message. 2. Section 5 - Relay agents implementing this specification SHOULD have a configuration parameter that determines whether or not they will relay a Relay-Forward message toward the DHCP server if it contains a Relay-Supplied Options option. Relay agents that have this configuration parameter and that are configured to enable this behavior MUST silently discard any Relay-Forward packet that contains a Relay-Supplied Options option. Suggested wording: Relay agents implementing this specification SHOULD have a configuration parameter that determines whether or not they will relay a Relay-Forward message toward the DHCP server if it contains a Relay-Supplied Options option. When this parameter is configured to be 'enabled', the relay MUST silently discard any Relay-Forward packet that contains a Relay-Supplied Options option. 3. Section 6 - When such a conflict exists, the DHCP server MUST choose no more than one of these options to forward to the client. The DHCP server MUST NOT forward more than one of these options to the client. Suggested wording: When a conflict exists, the DHCP server MUST NOT forward more than one of these options to forward to the client. 4. Section 7- This document provides a mechanism whereby a relay agent can inject options into the response the DHCP server sends to the DHCP client. Suggested wording: This document provides a mechanism whereby a relay agent can supply options to the DHCP client through the DHCP Server. 5. Section 7 - In some environments, there is an interface on one side of which is the client, and zero or more routers, and on the other side of which is a network managed by a monolithic or effectively monolithic administrative entity. Nodes and routers on the client side of the interface are not controlled by this entity, and are considered "untrusted." Nodes and routers on the other side of this interface are considered trusted. Suggested wording: In some environments, the relay agent acting as a $B!F(Btrusted$B!G(B device, which is managed by the administrative entity, connects to some $B!F(Buntrusted$B!G(B client networks, which are not controlled by this entity. Best Regards, Leaf --Boundary_(ID_6xeyVF2Wt/dxjcd3936xlQ) Content-id: <02B5588403E6A04DB85592CF78C20F9F@huawei.com> Content-type: text/html; charset=iso-2022-jp Content-transfer-encoding: quoted-printable

Hi Ted,

 

Not sure the following comments= are too late and will be helpful.

 

l  Questions of clarification:<= /o:p>

 

1.      Section 6 = - DHCP servers normally construct a list of options that are candidates to = send to the DHCP client, and then construct the DHCP packet according to se= ction 17.2.2 of DHCPv6 [RFC3315].

 

Not sure about that the re= ply message sent by the Server is Advertise (2) per 17.2.2 o= f RFC3315.

I guess the wording might = be '...construct the DHCP packet according to section 20.3 of DHCPv6&n= bsp;[RFC3315]. '

The message sent by the se= rver should also include the relay-reply (13) of Reply (7).

 

 

l  Suggestion on the wording revisio= ns for the convenient reference:

 

1.      Section 5 - Relay agents MAY include a Relay-Supplied Options option= in the option payload of a Relay-Forward message.

 

Suggested wording: Relay agents MAY include a Relay-Supplied Options option in a Relay-Fo= rward message.

 

2.      Section 5 = - Relay agents imp= lementing this specification SHOULD have a configuration parameter that det= ermines whether or not they will relay a Relay-Forward message toward the DHCP server if it contains a Relay-Suppli= ed Options option.

 

Relay agents that have this con= figuration parameter and that are configured to enable this behavior MUST s= ilently discard any Relay-Forward packet that contains a Relay-Supplied Opt= ions option.

Suggested wording: &= nbsp;Relay agents implementing this spe= cification SHOULD have a configuration parameter that determines whether or= not they will relay a Relay-Forward message toward the DHCP server if it contains a Relay-Supplied Options option. Whe= n this parameter is configured to be 'enabled', the relay MUST silently dis= card any Relay-Forward packet that contains a Relay-Supplied Options option= .

 

3.      Section 6 = -  When such a conflict exists, the DHCP server MUST choose no mo= re than one of these options to forward to the client. The DHCP server= MUST NOT forward more than one of these options to the client.

 

Suggested wording: When a confl= ict exists, the DHCP server MUST NOT forward more than one of these options= to forward to the client.

 

4.      Section 7-= This document provides a mechanism whereby a relay agent can inject option= s into the response the DHCP server sends to the DHCP client.

 

Suggested wording: This documen= t provides a mechanism whereby a relay agent can supply options to the DHCP= client through the DHCP Server.

 

5.      Section 7 - In some environments, there is an int= erface on one side of which is the client, and zero or more routers, and on the other side of which is a network mana= ged by a monolithic or effectively monolithic administrative entity.  = Nodes and routers on the client side of the interface are not controlled by= this entity, and are considered "untrusted."  Nodes and routers on the other side of this interface are considered trust= ed.

Suggested wording:  In some environments, the relay agent acting as a =1B$B!= F=1B(Btrusted=1B$B!G=1B(B device, which is managed by the administrative entity, connects to some =1B$B!F=1B(Buntrusted=1B$B!G=1B(B client networks, which are not controlled by = this entity.

 

 

Best Regards,

Leaf

--Boundary_(ID_6xeyVF2Wt/dxjcd3936xlQ)--