From list-dhcwg@dragon.net Mon Oct 1 02:16:28 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25E2421F84D3 for ; Mon, 1 Oct 2012 02:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 6rd7NTdrc4qT for ; Mon, 1 Oct 2012 02:16:27 -0700 (PDT) Received: from mail.dragon.net (mail.dragon.net [IPv6:2001:4f8:3:36::235]) by ietfa.amsl.com (Postfix) with ESMTP id 3D2FA21F84AE for ; Mon, 1 Oct 2012 02:16:27 -0700 (PDT) Received: from fafnir.remote.dragon.net (localhost [127.0.0.1]) by mail.dragon.net (Postfix) with ESMTP id 496273740893 for ; Mon, 1 Oct 2012 02:16:26 -0700 (PDT) Received: by fafnir.remote.dragon.net (Postfix, from userid 501) id 56EA91190FE4; Mon, 1 Oct 2012 13:16:25 +0400 (MSK) Received: from fafnir.remote.dragon.net (localhost [127.0.0.1]) by fafnir.remote.dragon.net (Postfix) with ESMTP id 4FF2A1190FDB for ; Mon, 1 Oct 2012 13:16:25 +0400 (MSK) To: dhc WG From: Paul Ebersman In-reply-to: References: Comments: In-reply-to Ted Lemon message dated "Wed, 19 Sep 2012 21:45:21 +0000." X-Mailer: MH-E 7.4.2; nmh 1.3; XEmacs 21.4 (patch 22) Date: Mon, 01 Oct 2012 13:16:25 +0400 Message-Id: <20121001091625.56EA91190FE4@fafnir.remote.dragon.net> Subject: Re: [dhcwg] Call for adoption: draft-lemon-dhc-pd-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, 01 Oct 2012 09:16:28 -0000 TLemon> I'd like the working group to work on this document. I think we should work on this document. Agree that a DNSOPS review would be handy. From list-dhcwg@dragon.net Mon Oct 1 02:26:01 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14E6321F85E6 for ; Mon, 1 Oct 2012 02:26:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_35=0.6] 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 HkGuk8vQW-k5 for ; Mon, 1 Oct 2012 02:26:00 -0700 (PDT) Received: from mail.dragon.net (mail.dragon.net [IPv6:2001:4f8:3:36::235]) by ietfa.amsl.com (Postfix) with ESMTP id A153D21F8587 for ; Mon, 1 Oct 2012 02:26:00 -0700 (PDT) Received: from fafnir.remote.dragon.net (localhost [127.0.0.1]) by mail.dragon.net (Postfix) with ESMTP id DC7703740893 for ; Mon, 1 Oct 2012 02:25:59 -0700 (PDT) Received: by fafnir.remote.dragon.net (Postfix, from userid 501) id AE77C119123D; Mon, 1 Oct 2012 13:25:58 +0400 (MSK) Received: from fafnir.remote.dragon.net (localhost [127.0.0.1]) by fafnir.remote.dragon.net (Postfix) with ESMTP id A91EB1191234 for ; Mon, 1 Oct 2012 13:25:58 +0400 (MSK) To: dhc WG From: Paul Ebersman In-reply-to: References: Comments: In-reply-to Ted Lemon message dated "Fri, 21 Sep 2012 12:08:41 +0000." X-Mailer: MH-E 7.4.2; nmh 1.3; XEmacs 21.4 (patch 22) Date: Mon, 01 Oct 2012 13:25:58 +0400 Message-Id: <20121001092558.AE77C119123D@fafnir.remote.dragon.net> Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 09:26:01 -0000 TLemon> The authors have sub,tired a new version of this document to TLemon> address concerns raised in the previous WGLC. If you TLemon> participated in the previous WGLC or want to participate now, TLemon> please review the (short) draft and send comments to the mailing TLemon> list if you have any. Also please indicate whether you support TLemon> advancing the draft at this time or not. I support advancing this draft. From list-dhcwg@dragon.net Mon Oct 1 06:59:48 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D8731F0D56 for ; Mon, 1 Oct 2012 06:59:48 -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] 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 gku59l1iNTdf for ; Mon, 1 Oct 2012 06:59:47 -0700 (PDT) Received: from mail.dragon.net (mail.dragon.net [IPv6:2001:4f8:3:36::235]) by ietfa.amsl.com (Postfix) with ESMTP id C75161F0CF9 for ; Mon, 1 Oct 2012 06:59:47 -0700 (PDT) Received: from fafnir.remote.dragon.net (localhost [127.0.0.1]) by mail.dragon.net (Postfix) with ESMTP id 2E5D23740639 for ; Mon, 1 Oct 2012 06:59:45 -0700 (PDT) Received: by fafnir.remote.dragon.net (Postfix, from userid 501) id 3DF7E1195AB1; Mon, 1 Oct 2012 17:59:45 +0400 (MSK) Received: from fafnir.remote.dragon.net (localhost [127.0.0.1]) by fafnir.remote.dragon.net (Postfix) with ESMTP id 3D9741195AB0 for ; Mon, 1 Oct 2012 17:59:45 +0400 (MSK) To: dhcwg WG From: Paul Ebersman In-reply-to: References: Comments: In-reply-to Ted Lemon message dated "Wed, 26 Sep 2012 17:27:09 +0000." X-Mailer: MH-E 7.4.2; nmh 1.3; XEmacs 21.4 (patch 22) Date: Mon, 01 Oct 2012 17:59:45 +0400 Message-Id: <20121001135945.3DF7E1195AB1@fafnir.remote.dragon.net> Subject: Re: [dhcwg] Call for adoption: draft-mrugalski-softwire-dhcpv4-over-v6-option-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, 01 Oct 2012 13:59:48 -0000 TLemon> The authors have requested that the working group adopt TLemon> draft-mrugalski-softwire-dhcpv4-over-v6-option as a working TLemon> group work item. I support working on this draft. From internet-drafts@ietf.org Tue Oct 2 19:45:19 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EAA521F8595; Tue, 2 Oct 2012 19:45:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.513 X-Spam-Level: X-Spam-Status: No, score=-102.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 XJ+STSJkmRuX; Tue, 2 Oct 2012 19:45:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3237221F85A1; Tue, 2 Oct 2012 19:45:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121003024519.9926.80712.idtracker@ietfa.amsl.com> Date: Tue, 02 Oct 2012 19:45:19 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-client-id-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: Wed, 03 Oct 2012 02:45:19 -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 Group = of the IETF. Title : Client Identifier Option in DHCP Server Replies Author(s) : Narasimha Swamy Gaurav Halwasia Prashant Jhingran Filename : draft-ietf-dhc-client-id-06.txt Pages : 7 Date : 2012-10-02 Abstract: This document updates RFC2131 [RFC2131]. The changes to [RFC2131] defined in this draft clarifies the use of 'client identifier' option by the DHCP servers. The clarification addresses the issues arising out of the point specified by [RFC2131] that the server 'MUST NOT' return client identifier' option to the client. Requirements The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-client-id There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-client-id-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-client-id-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From iesg-secretary@ietf.org Wed Oct 3 13:44:56 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1167A1F0425; Wed, 3 Oct 2012 13:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.077, 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 kJsdDPy9BYgs; Wed, 3 Oct 2012 13:44:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 925A921F84EB; Wed, 3 Oct 2012 13:44:55 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121003204455.25643.52075.idtracker@ietfa.amsl.com> Date: Wed, 03 Oct 2012 13:44:55 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] Last Call: (Client Identifier Option in DHCP Server Replies) 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, 03 Oct 2012 20:44:56 -0000 The IESG has received a request from the Dynamic Host Configuration WG (dhc) to consider the following document: - 'Client Identifier Option in DHCP Server Replies' as 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 2012-10-17. 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 updates RFC2131 [RFC2131]. The changes to [RFC2131] defined in this draft clarifies the use of 'client identifier' option by the DHCP servers. The clarification addresses the issues arising out of the point specified by [RFC2131] that the server 'MUST NOT' return client identifier' option to the client. Requirements The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dhc-client-id/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dhc-client-id/ballot/ No IPR declarations have been submitted directly on this I-D. From Ted.Lemon@nominum.com Fri Oct 5 12:30:57 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28ABD21F87C5 for ; Fri, 5 Oct 2012 12:30:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.743 X-Spam-Level: X-Spam-Status: No, score=-105.743 tagged_above=-999 required=5 tests=[AWL=-0.633, BAYES_05=-1.11, 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 thav6r6iayXL for ; Fri, 5 Oct 2012 12:30:56 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id 2001C21F87BE for ; Fri, 5 Oct 2012 12:30:56 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKUG81bUu8GV9iemEH7XVGVr/zEHRJe6mW@postini.com; Fri, 05 Oct 2012 12:30: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 98A7D1B829B for ; Fri, 5 Oct 2012 12:30:52 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 8E5FB19005C for ; Fri, 5 Oct 2012 12:30:52 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Fri, 5 Oct 2012 12:30:52 -0700 From: Ted Lemon To: dhcwg WG Thread-Topic: [dhcwg] Call for adoption: draft-mrugalski-softwire-dhcpv4-over-v6-option-01 Thread-Index: AQHNoy/uq3cHivY9BE+NDMQ1LryF/A== Date: Fri, 5 Oct 2012 19:30:52 +0000 Message-ID: <93BA6FCE-4EAF-4F56-9E4F-B6E389834A41@nominum.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] Call for adoption: draft-mrugalski-softwire-dhcpv4-over-v6-option-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, 05 Oct 2012 19:30:57 -0000 On Sep 26, 2012, at 1:27 PM, Ted Lemon wrote: > The authors have requested that the working group adopt draft-mrugalski-s= oftwire-dhcpv4-over-v6-option as a working group work item. The document = is within the scope of the current charter. It describes a DHCPv6 option = that is used to configure client relay agents (draft-ietf-dhc-dhcpv4-over-i= pv6). Just a reminder: we have only seen two responses on this draft, and I know = that there are more than two working group participants who are interested = in it. The call for adoption expires on October 10. FTR, with my wg chair hat off, I'm in favor of adopting. From david@pheynix.net Fri Oct 5 15:56:01 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6041E21F84D6 for ; Fri, 5 Oct 2012 15:56: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 WNvwJsweBrB2 for ; Fri, 5 Oct 2012 15:56:00 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id B3CA721F84D3 for ; Fri, 5 Oct 2012 15:56:00 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so5939114iec.31 for ; Fri, 05 Oct 2012 15:56:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pheynix.net; s=google; h=date:from:to:message-id:subject:x-mailer:mime-version:content-type :content-transfer-encoding:content-disposition; bh=axyu3wsTd4hXX3DNPcIJt8VqCkEO+PPw2ArTEt0Cwtw=; b=jseVHvN7YHEyn41pWbcD1pa72yofPkcSZV6k4TKsce26/WnhUgCv/DD/To4TBNNbtY +g1xtU5KfV1HCX0A1ye4d0wuPNGN5rs4sAIC7DknltyGLH/9qd9Qy8Nn5NWHHAmPFle8 bw9RJS753YpboSKUjATi7148Z82MnslfuR6yU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:message-id:subject:x-mailer:mime-version:content-type :content-transfer-encoding:content-disposition:x-gm-message-state; bh=axyu3wsTd4hXX3DNPcIJt8VqCkEO+PPw2ArTEt0Cwtw=; b=NtxFWNkT3n30bBdodsT4Y+NZ1L5lG3BNVZmCVp334H+o/Nk9TttP/I9ILmQm8OUu65 86dF6PReuXiBkbYhoUS5pHon6/497uZ1qTfy0Nw5SUkICINLy9zoH42UmTu96FIR+VVi boSDEQhQPTOUVUh2xJ44O8UUMqRWJHmh1Ast20g4oWnn2FuJ/1K9wcnWgVyCKKAkE3rd 0tZSdHDRavdmims7ubab6sbbsDuwjnXLEoM4jSZCVCSw6I6wKBzcyiNanJRH363W584F s+BvN0oB1lnj6+zMtxw9OLyIbq4xrqMaYrSFkfQV4X4PeMSrM+fxxWeBmi0GGJaurDWt bNMQ== Received: by 10.50.173.41 with SMTP id bh9mr290892igc.52.1349477760094; Fri, 05 Oct 2012 15:56:00 -0700 (PDT) Received: from [10.33.1.100] (184-96-184-160.hlrn.qwest.net. [184.96.184.160]) by mx.google.com with ESMTPS id y9sm1877514igm.10.2012.10.05.15.55.59 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 05 Oct 2012 15:55:59 -0700 (PDT) Date: Fri, 5 Oct 2012 16:55:57 -0600 From: David Miles To: dhcwg@ietf.org Message-ID: X-Mailer: sparrow 1.6.4 (build 1176) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Gm-Message-State: ALoCoQljuqVt6oglqW8kddHE8XP02c/eKTKYA4pAzJP1cg7cwW7apyAPWQ2IZqOPKwTRtSD/tYh9 Subject: [dhcwg] DHCPv6 NoAddrAvailable 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, 05 Oct 2012 22:56:01 -0000 I have run across two different implementations of DHCPv6 server wrt NoAddrAvail/NoPrefixAvail and was hoping to get some thoughts what is best practice and what is non-compliant. In my case, IA_NA and IA_PD are present in the solicit. The responses are: Server A:- Advertise Client-Id Server-Id Status Code: NoPrefixAvail Status Code: NoAddrAvail Server B:- Advertise Client-Id Server-Id IA_NA Status Code: NoAddrAvail IA_PD Status Code: NoPrefixAvail IMO a client should be able to handle both cases (as server B is a superset of existing RFC requirements), but a server MUST send like A according to the RFC (I think?) when there are no addresses at all to offer. And to be interesting, I assume that if there were addresses available but no prefixes, the Server B example (but with valid IA_NA) is the correct approach? Thoughts? d From Stephen.Jacob@nominum.com Fri Oct 5 17:21:24 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD0D721F8653 for ; Fri, 5 Oct 2012 17:21: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 n6ZBSFIxGcZV for ; Fri, 5 Oct 2012 17:21:24 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 9D55721F8648 for ; Fri, 5 Oct 2012 17:21:21 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKUG95gXbomF3sFAAQMoKP1vTpmkNyw+n5@postini.com; Fri, 05 Oct 2012 17:21:23 PDT Received: by shell-too.nominum.com (Postfix, from userid 11053) id A1B111B82C7; Fri, 5 Oct 2012 17:21:20 -0700 (PDT) Date: Fri, 5 Oct 2012 17:21:20 -0700 From: Stephen Jacob To: David Miles Message-ID: <20121006002120.GA22039@shell-too.nominum.com> Mail-Followup-To: David Miles , 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 NoAddrAvailable 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, 06 Oct 2012 00:21:24 -0000 On Fri, Oct 05, 2012 at 04:55:57PM -0600, David Miles wrote: > I have run across two different implementations of DHCPv6 server wrt > NoAddrAvail/NoPrefixAvail and was hoping to get some thoughts what is > best practice and what is non-compliant. > > In my case, IA_NA and IA_PD are present in the solicit. The responses are: > > Server A:- > Advertise > Client-Id > Server-Id > Status Code: NoPrefixAvail > Status Code: NoAddrAvail > > > Server B:- > Advertise > Client-Id > Server-Id > IA_NA > Status Code: NoAddrAvail > IA_PD > Status Code: NoPrefixAvail > > IMO a client should be able to handle both cases (as server B is a > superset of existing RFC requirements), but a server MUST send like A > according to the RFC (I think?) when there are no addresses at all to > offer. > > And to be interesting, I assume that if there were addresses available > but no prefixes, the Server B example (but with valid IA_NA) is the > correct approach? > > Thoughts? Ole and Bernie have been attempting to fix this case up a bit in https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-stateful-issues/ That said, it's an annoying problem. Prior to considering IA_PD, it seemed to make sense to have a NoAddrsAvail at the top-level when not returning any bindings, so you didn't have to include multiple IA options which just said NoAddrsAvail. Unfortunately, it turned out to be a decision which has not worked out well with the addition of IA_PD into the mix. Since you cannot both indicate successful prefix assignment and unsuccessful address assignment with one status code at the top level, and since RFC 3315 says you MUST include a status of NoAddsAvail if you don't assign any addresses ... it has been a bit of a mess. Server A is acting in a way that most closely fits the standards, but Server B is doing the thing that would be least confusing. Bernie and Ole's draft at least removes the contradictions and confusion, but I wish we could hit reset and do it right (status codes only in IA options). Hopefully draft-ietf-dhc-dhcpv6-stateful-issues answers the question of what one should do adequately. Regards, Stephen -- Stephen Jacob | Stephen.Jacob@nominum.com | +1 650 381 6051 Nominum, Inc. | http://www.nominum.com/ | +1 650 381 6000 From internet-drafts@ietf.org Fri Oct 5 19:09:17 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAB6121F856C; Fri, 5 Oct 2012 19:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.5 X-Spam-Level: X-Spam-Status: No, score=-102.5 tagged_above=-999 required=5 tests=[AWL=0.099, 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 ow4H2SqhUm9A; Fri, 5 Oct 2012 19:09:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61C2D21F8559; Fri, 5 Oct 2012 19:09: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: 4.34 Message-ID: <20121006020917.14172.8876.idtracker@ietfa.amsl.com> Date: Fri, 05 Oct 2012 19:09:17 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Oct 2012 02:09:18 -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 Group = of the IETF. Title : Issues with multiple stateful DHCPv6 options Author(s) : Ole Troan Bernie Volz Filename : draft-ietf-dhc-dhcpv6-stateful-issues-01.txt Pages : 10 Date : 2012-10-05 Abstract: Dynamic Host Configuration Protocol for IPv6 (DHCPv6) was not written with the expectation that additional stateful DHCPv6 options would be developed. IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6 shoe-horned the new options for Prefix Delegation into DHCPv6. Implementation experience of the CPE model described in has shown multiple issues with the DHCPv6 protocol in supporting multiple stateful options. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-stateful-issues There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-stateful-issues-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-dhcpv6-stateful-issues-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From volz@cisco.com Fri Oct 5 19:20:10 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9AE621F861C for ; Fri, 5 Oct 2012 19:20:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.484 X-Spam-Level: X-Spam-Status: No, score=-10.484 tagged_above=-999 required=5 tests=[AWL=0.115, 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 qJfjHZ5Jcx17 for ; Fri, 5 Oct 2012 19:20:09 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 13BCE21F8619 for ; Fri, 5 Oct 2012 19:20:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2435; q=dns/txt; s=iport; t=1349490009; x=1350699609; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=VvTN5HXF0HDEMz5IM7EQA4tlly5LaOZDt3jelCpqg+I=; b=aAeHJLZQLC6LXkMPWeO2zvND//DlEGLaDbP/G6jl5SaDiSjQcJcQPqJw /EKpkTjG37aqP5MXwPPseNc41vwpvFoTG7nOTVZWDiLsbU6ttQ+lurMe8 vunlOBee2KJguWH3t6voOlnEPOnLYuazygcws0BryCV/WgBaJlrHBPbkl M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFCUb1CtJV2b/2dsb2JhbABFvyCBCIIgAQEBBAEBAQ8BJzQXBAIBCBEEAQELFAkHJwsUCQgCBBMIARmHYwuZGZ96iz6FKWADlwCNMIFpgm2CFw X-IronPort-AV: E=Sophos;i="4.80,543,1344211200"; d="scan'208";a="128867029" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 06 Oct 2012 02:20:08 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q962K8t0014195 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 6 Oct 2012 02:20:08 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.206]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.001; Fri, 5 Oct 2012 21:20:08 -0500 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-01.txt Thread-Index: AQHNo2eaBMdU+nxk/UK9wC1g66rtJZeriLWw Date: Sat, 6 Oct 2012 02:20:07 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E0F5271B9@xmb-rcd-x04.cisco.com> References: <20121006020917.14172.8876.idtracker@ietfa.amsl.com> In-Reply-To: <20121006020917.14172.8876.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.248.151] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19242.001 x-tm-as-result: No--27.371200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Oct 2012 02:20:10 -0000 I updated the draft after some (offline) discussions with Hemant and Ole. The major changes were: - Section 4.0 - added more text to clarify the goal of the changes in the s= ections that follow (this text came from the old 4.6 section). - Section 4.1 - improved the text a bit. - Section 4.4 - is "new" and discusses Renew and Rebind message handling (t= his was in the old 4.6 section but with less detail). - Section 4.5 (which was 4.4) - expands on the changes for Confirm handling= for PD. - Section 4.7 - added text that RFC 3315/3633 assumed the single provisioni= ng domain model. - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of i= nternet-drafts@ietf.org Sent: Friday, October 05, 2012 10:09 PM To: i-d-announce@ietf.org Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-01.txt 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 Group = of the IETF. Title : Issues with multiple stateful DHCPv6 options Author(s) : Ole Troan Bernie Volz Filename : draft-ietf-dhc-dhcpv6-stateful-issues-01.txt Pages : 10 Date : 2012-10-05 Abstract: Dynamic Host Configuration Protocol for IPv6 (DHCPv6) was not written with the expectation that additional stateful DHCPv6 options would be developed. IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6 shoe-horned the new options for Prefix Delegation into DHCPv6. Implementation experience of the CPE model described in has shown multiple issues with the DHCPv6 protocol in supporting multiple stateful options. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-stateful-issues There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-stateful-issues-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-dhcpv6-stateful-issues-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From volz@cisco.com Fri Oct 5 19:28:19 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A429121F861D for ; Fri, 5 Oct 2012 19:28:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.229 X-Spam-Level: X-Spam-Status: No, score=-10.229 tagged_above=-999 required=5 tests=[AWL=0.370, 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 iEWSnIVUNpE5 for ; Fri, 5 Oct 2012 19:28:18 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id C30A621F861C for ; Fri, 5 Oct 2012 19:28:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3544; q=dns/txt; s=iport; t=1349490498; x=1350700098; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=wbz8Fzu0m2XoeSTXIWf8Lq4pESaarqtZ4+dlVobn5I8=; b=RL2aApV6k9fwICidB0h5jE9hph9ORoU6pH2pOhNd29YdZpDAxJDEgVDm cEtTtVku+FRbl+KyQfczYiMlRfjEJ6zmDKxo6/qu/Dwygt59OI4WR2UUF 602YERpLHhUrZZ3LNzBx7q8PDHdSLUbTV/+jqJ//X3qudEzpOqq/4niDu 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALiWb1CtJV2c/2dsb2JhbABCA78ggQiCIAEBAQQBAQEPASc0CwwEAgEIBwoEAQEBChQJBycLFAkIAgQBDQUIGodjC5kTn3iCQ4h7gmOCRmADkjqRdoFpgm2CFw X-IronPort-AV: E=Sophos;i="4.80,543,1344211200"; d="scan'208";a="128848127" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 06 Oct 2012 02:28:18 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q962SIDU013094 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 6 Oct 2012 02:28:18 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.206]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.001; Fri, 5 Oct 2012 21:28:17 -0500 From: "Bernie Volz (volz)" To: Stephen Jacob , David Miles Thread-Topic: [dhcwg] DHCPv6 NoAddrAvailable Thread-Index: AQHNo0ybecTMmH+I0k60gxCF7L3bFpervjwA///NmJA= Date: Sat, 6 Oct 2012 02:28:16 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E0F5271DD@xmb-rcd-x04.cisco.com> References: <20121006002120.GA22039@shell-too.nominum.com> In-Reply-To: <20121006002120.GA22039@shell-too.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.248.151] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19242.001 x-tm-as-result: No--38.796500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] DHCPv6 NoAddrAvailable 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, 06 Oct 2012 02:28:19 -0000 Actually, the correct answer should be: Server C:- Advertise Client-Id Server-Id IA_PD Status Code: NoPrefixAvail Status Code: NoAddrsAvail You can change the order of the options, but RFC 3315 is pretty clear that = the NoAddrsAvail should be a 'top' level status code in this case. The text= in RFC 3315 is in section 17.2.2: If the server will not assign any addresses to any IAs in a subsequent Request from the client, the server MUST send an Advertise message to the client that includes only a Status Code option with code NoAddrsAvail and a status message for the user, a Server Identifier option with the server's DUID, and a Client Identifier option with the client's DUID. RFC 3633 is clear that the NoPrefixAvail is in the IA_PD option. - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of S= tephen Jacob Sent: Friday, October 05, 2012 8:21 PM To: David Miles Cc: dhcwg@ietf.org Subject: Re: [dhcwg] DHCPv6 NoAddrAvailable On Fri, Oct 05, 2012 at 04:55:57PM -0600, David Miles wrote: > I have run across two different implementations of DHCPv6 server wrt > NoAddrAvail/NoPrefixAvail and was hoping to get some thoughts what is > best practice and what is non-compliant. >=20 > In my case, IA_NA and IA_PD are present in the solicit. The responses are= : >=20 > Server A:- > Advertise > Client-Id > Server-Id > Status Code: NoPrefixAvail > Status Code: NoAddrAvail >=20 >=20 > Server B:- > Advertise > Client-Id > Server-Id > IA_NA > Status Code: NoAddrAvail > IA_PD > Status Code: NoPrefixAvail >=20 > IMO a client should be able to handle both cases (as server B is a > superset of existing RFC requirements), but a server MUST send like A > according to the RFC (I think?) when there are no addresses at all to > offer. >=20 > And to be interesting, I assume that if there were addresses available > but no prefixes, the Server B example (but with valid IA_NA) is the > correct approach? >=20 > Thoughts? Ole and Bernie have been attempting to fix this case up a bit in https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-stateful-issues/ That said, it's an annoying problem. Prior to considering IA_PD, it seemed to make sense to have a NoAddrsAvail at the top-level when not returning any bindings, so you didn't have to include multiple IA options which just said NoAddrsAvail. Unfortunately, it turned out to be a decision which has not worked out well with the addition of IA_PD into the mix. Since you cannot both indicate successful prefix assignment and unsuccessful address assignment with one status code at the top level, and since RFC 3315 says you MUST include a status of NoAddsAvail if you don't assign any addresses ... it has been a bit of a mess. Server A is acting in a way that most closely fits the standards, but Server B is doing the thing that would be least confusing. Bernie and Ole's draft at least removes the contradictions and confusion, but I wish we could hit reset and do it right (status codes only in IA options). Hopefully draft-ietf-dhc-dhcpv6-stateful-issues answers the question of what one should do adequately. 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 ian.farrer@telekom.de Sat Oct 6 04:10:16 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAF9D21F858F for ; Sat, 6 Oct 2012 04:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 bYh6h+YoE0jr for ; Sat, 6 Oct 2012 04:10:16 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by ietfa.amsl.com (Postfix) with ESMTP id 101E821F8582 for ; Sat, 6 Oct 2012 04:10:15 -0700 (PDT) Received: from he113656.emea1.cds.t-internal.com ([10.134.99.16]) by tcmail81.telekom.de with ESMTP/TLS/AES128-SHA; 06 Oct 2012 13:10:14 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113656.emea1.cds.t-internal.com ([::1]) with mapi; Sat, 6 Oct 2012 13:10:13 +0200 From: To: Date: Sat, 6 Oct 2012 13:10:12 +0200 Thread-Topic: Re: [dhcwg] Call for adoption: draft-mrugalski-softwire-dhcpv4-over-v6-option-01 Thread-Index: Ac2jsyfrF7RI3k4MTeqHMGm/3YntiA== Message-ID: <8A1B81989BCFAE44A22B2B86BF2B7631893D089086@HE111643.EMEA1.CDS.T-INTERNAL.COM> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: multipart/alternative; boundary="_000_8A1B81989BCFAE44A22B2B86BF2B7631893D089086HE111643EMEA1_" MIME-Version: 1.0 Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Call for adoption: draft-mrugalski-softwire-dhcpv4-over-v6-option-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: Sat, 06 Oct 2012 11:10:17 -0000 --_000_8A1B81989BCFAE44A22B2B86BF2B7631893D089086HE111643EMEA1_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ted, I support the adoption of this draft as a workgroup item. Thanks, Ian ------------------------ The authors have requested that the working group adopt draft-mrugalski-sof= twire-dhcpv4-over-v6-option as a working group work item. The document is w= ithin the scope of the current charter. It describes a DHCPv6 option that i= s used to configure client relay agents (draft-ietf-dhc-dhcpv4-over-ipv6). If you think the working group should be working on such an option, please = respond to this message by saying so. If you think we should not, please say that. We will evaluate consensus on = or after October 10. --_000_8A1B81989BCFAE44A22B2B86BF2B7631893D089086HE111643EMEA1_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Ted,
I support the adoption= of this draft as a workgroup item.
Thanks,
Ian
----------------------= --
The authors have reque= sted that the working group adopt draft-mrugalski-softwire-dhcpv4-over-v6-o= ption as a working group work item. The document is within the scope of the= current charter. It describes a DHCPv6 option that is used to configure client relay agents (draft-ietf-dhc-dhcpv4= -over-ipv6).
If you think the worki= ng group should be working on such an option, please respond to this messag= e by saying so.
If you think we should= not, please say that. We will evaluate consensus on or after October 10. <= /div>
 
 
 --_000_8A1B81989BCFAE44A22B2B86BF2B7631893D089086HE111643EMEA1_-- From shemant@cisco.com Sat Oct 6 06:17:35 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D514421F859C for ; Sat, 6 Oct 2012 06:17:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.421 X-Spam-Level: X-Spam-Status: No, score=-10.421 tagged_above=-999 required=5 tests=[AWL=0.178, 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 KeaR32aunC9C for ; Sat, 6 Oct 2012 06:17:35 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 0548F21F855F for ; Sat, 6 Oct 2012 06:17:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2952; q=dns/txt; s=iport; t=1349529455; x=1350739055; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=cQYJjJUinaxiQ2yPMCMy7yBys9GI7MbDOdXDhNAgqBU=; b=XY8gUr89i8SvDDA3qvfeXNQIze34Afld+iUcip3TiGhg3YByT1X5IZzY cNZpxzvQVYJxpW6zoyQyBQEGv5t3tfJcpe0E1av+eeYrHm4unPo0Ag77m mU4iMfDeDIz7ngpbfLAMtOagE1i8mriyc1lQhqNY9sjXIWXdaKJXacDUA U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAMkucFCtJV2Y/2dsb2JhbABFvyGBCIIgAQEBBAEBAQ8BJzQXBAIBCBEEAQELFAkHJwsUCQgCBAESCAEZh2MLmV6fWYtPhTBgA5cAjTCBaYJtghc X-IronPort-AV: E=Sophos;i="4.80,543,1344211200"; d="scan'208";a="128962141" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP; 06 Oct 2012 13:17:34 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q96DHYkW026621 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 6 Oct 2012 13:17:34 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.182]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.001; Sat, 6 Oct 2012 08:17:34 -0500 From: "Hemant Singh (shemant)" To: "Bernie Volz (volz)" , "dhcwg@ietf.org" Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-01.txt Thread-Index: AQHNo2eapo9ewo2MvUm9MODxPn3scZer3zaAgABjdjA= Date: Sat, 6 Oct 2012 13:17:33 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B890CA564@xmb-rcd-x06.cisco.com> References: <20121006020917.14172.8876.idtracker@ietfa.amsl.com> <489D13FBFA9B3E41812EA89F188F018E0F5271B9@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E0F5271B9@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.252.144] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19246.000 x-tm-as-result: No--30.954600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Oct 2012 13:17:36 -0000 This new version of the document looks good to me and ready for a review by= the IESG. =20 Thanks, Hemant -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of B= ernie Volz (volz) Sent: Friday, October 05, 2012 10:20 PM To: dhcwg@ietf.org Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-01.t= xt I updated the draft after some (offline) discussions with Hemant and Ole. The major changes were: - Section 4.0 - added more text to clarify the goal of the changes in the s= ections that follow (this text came from the old 4.6 section). - Section 4.1 - improved the text a bit. - Section 4.4 - is "new" and discusses Renew and Rebind message handling (t= his was in the old 4.6 section but with less detail). - Section 4.5 (which was 4.4) - expands on the changes for Confirm handling= for PD. - Section 4.7 - added text that RFC 3315/3633 assumed the single provisioni= ng domain model. - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of i= nternet-drafts@ietf.org Sent: Friday, October 05, 2012 10:09 PM To: i-d-announce@ietf.org Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-01.txt 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 Group = of the IETF. Title : Issues with multiple stateful DHCPv6 options Author(s) : Ole Troan Bernie Volz Filename : draft-ietf-dhc-dhcpv6-stateful-issues-01.txt Pages : 10 Date : 2012-10-05 Abstract: Dynamic Host Configuration Protocol for IPv6 (DHCPv6) was not written with the expectation that additional stateful DHCPv6 options would be developed. IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6 shoe-horned the new options for Prefix Delegation into DHCPv6. Implementation experience of the CPE model described in has shown multiple issues with the DHCPv6 protocol in supporting multiple stateful options. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-stateful-issues There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-stateful-issues-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-dhcpv6-stateful-issues-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ 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 david@pheynix.net Sat Oct 6 10:01:45 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 344CB21F853A for ; Sat, 6 Oct 2012 10:01:45 -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 6EJCh5Tgv+sx for ; Sat, 6 Oct 2012 10:01:44 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7282521F84EA for ; Sat, 6 Oct 2012 10:01:44 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so7290125iec.31 for ; Sat, 06 Oct 2012 10:01:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pheynix.net; s=google; h=date:from:to:cc:message-id:in-reply-to:references:subject:x-mailer :mime-version:content-type:content-transfer-encoding :content-disposition; bh=P5Yp2aLOG3ScmVUfsAq5l6hhQvclxtDhFUDe+vc7sRU=; b=W8c5skZoxHLhlnQeZuRit3HjRbJ9BH4ePAaadqLbPJL/KvdMvLKh1J5/jV+fv7n86c oK2Evldkwl0E2WJwOtd1AOYyk1mqJWuMUrMfq+x0LTKucb9/QFrsRXEWcGXn+oKoXn5K J1jDl6hvojiucfkqwHTSwUPj3wdK+ZIXksJd0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject:x-mailer :mime-version:content-type:content-transfer-encoding :content-disposition:x-gm-message-state; bh=P5Yp2aLOG3ScmVUfsAq5l6hhQvclxtDhFUDe+vc7sRU=; b=bKyGGK67GRz2bk/KP0hk2HF+uC525u1tXqXb8ReG3vTkynTXNb0XlKiMm0cLzN0s5Q ydLoaqw2Q7HrNYKerKvsh9b0/5l5XX6Qg0bpW4oU4S4ajwC4Q2b+++JHsC3lHENtiVtu xfGKq3QyF03rzD8oSmSmgspFrgyE8tnPIQ08c/5Wrxr543H/yzPMY3BGC26PjWh6CpXA vJXf9C4orgOAM9JrdtImzclvZQHiNQVoRAyF8ZTS2gC+C93v2p9+cyTHSUNZb8ygeG9e 4QU/oT4qMWHyOMKannZgYUNmfZO2MI6TAbnHbQSeuPBmhPzIHmsE/RnfS8WX//dz7r+C x1SQ== Received: by 10.50.155.193 with SMTP id vy1mr1823289igb.50.1349542903933; Sat, 06 Oct 2012 10:01:43 -0700 (PDT) Received: from [10.33.1.105] (184-96-184-160.hlrn.qwest.net. [184.96.184.160]) by mx.google.com with ESMTPS id bh3sm480684igc.0.2012.10.06.10.01.42 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 06 Oct 2012 10:01:43 -0700 (PDT) Date: Sat, 6 Oct 2012 11:01:42 -0600 From: David Miles To: "Bernie Volz (volz)" Message-ID: <3DA1744868D7494E82766FBA8C916EAE@pheynix.net> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E0F5271DD@xmb-rcd-x04.cisco.com> References: <20121006002120.GA22039@shell-too.nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F5271DD@xmb-rcd-x04.cisco.com> X-Mailer: sparrow 1.6.4 (build 1176) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Gm-Message-State: ALoCoQmEAiT3JLdTKQGwPatpTEvu4Zg1hGiSYeqrcbXXVHxSKriulrK+8ko0ojbWHMxRnaVY1CIh Cc: "=?utf-8?Q?dhcwg=40ietf.org?=" Subject: Re: [dhcwg] DHCPv6 NoAddrAvailable 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, 06 Oct 2012 17:01:45 -0000 On =46riday, October 5, 2012 at 8:28 PM, Bernie Volz (volz) wrote: > Actually, the correct answer should be: > =20 > Server C:- > Advertise > Client-Id > Server-Id > IA=5FPD > Status Code: NoPrefixAvail > Status Code: NoAddrsAvail > =20 Bernie, =20 thanks for the example. So in the mixed case (some IA have addresses/pref= ixes and others don't) and trying to remain compliant with section 18.1.8= : The client examines the status code in each IA individually. If the statu= s code is NoAddrsAvail, the client has received no usable addresses in th= e IA and may choose to try obtaining addresses for the IA from another se= rver. It suggests that when there is a multiple IA combination with differing l= evels of success, then the status code must always be in the IA=3F By putting the Status Code NoAddrAvailable at the 'top' level then the te= xt of 17.1.3 =5BThe client MUST ignore any Advertise message that include= s a Status Code option containing the value NoAddrsAvail, with the except= ion that the client MAY display the associated status message to the user= .=5D, it seems a server MUST NOT put a status code at the top level unle= ss all IA have NoAddrAvail and NoPrefixesAvail. In the cases where there = are mixed results the status codes should be within the appropriate IA=3F= Perhaps this is where the confusion is, as it is not explicit that an Adv= ertise in which IA have mixed results/status codes should employ those st= atus codes at the IA level. I appreciate it wasn't my question, but I wan= ted to be sure this corner case didn't change any of the suggested best p= ractice work =C3=98le and you are working on. cheers again d From david@pheynix.net Sat Oct 6 10:05:40 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAA3D21F8550 for ; Sat, 6 Oct 2012 10:05:40 -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 RRbLo2BsV7Y9 for ; Sat, 6 Oct 2012 10:05:40 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2554921F853A for ; Sat, 6 Oct 2012 10:05:40 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so7295165iec.31 for ; Sat, 06 Oct 2012 10:05:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pheynix.net; s=google; h=date:from:to:cc:message-id:in-reply-to:references:subject:x-mailer :mime-version:content-type:content-transfer-encoding :content-disposition; bh=zL/RokjgJtT37Yxg++bpuRVPpq6bHclDSuJ89t0sX2Q=; b=A1ASemble15NYiFXqlpNm9pZke23K2233vMHoF/DwkbIKFtGdE6MRops3PwPYnlmDU BlKNuaTProJ+F4e15hCdrFsw3tbs27fvcQlEB0iaOcein6OsGtr/A65ZHaxPc+CLSZd9 uPnjv/SLxHl+WpZQ46t6TYBTH7Z35BjLDnEz0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject:x-mailer :mime-version:content-type:content-transfer-encoding :content-disposition:x-gm-message-state; bh=zL/RokjgJtT37Yxg++bpuRVPpq6bHclDSuJ89t0sX2Q=; b=h6/NIyBD7lJkbodbsHm0VtpAqF1qJew1tW940jFmAk+9wkJUqpNrYViF4P+TXLQho3 wvCOqgtgFn/ERgxT/JIeVCu8we284Sx77q4Q/Y6RnuXvvT7OlGI1iYJRG2Sut4MpOUnH pW+FWQxOd1PJYaxtzc69prXOekBjBvpiTq+YWD6+YOkGf/daLaudatus2PQjkeKwVX1s Qla0Q/D7qXqtAT1kA5jdOkHjs976zXDP+wXltq0GVuwbf7CSEf+zWNlvbYUyZO3wSaa3 StDjfRVi+gYLcvYEoUvJhkLdv8BP74f6B9286rJcZ4ob22F84D+UsRtioNAL374/sdoK QVSQ== Received: by 10.50.37.135 with SMTP id y7mr4148181igj.36.1349543137839; Sat, 06 Oct 2012 10:05:37 -0700 (PDT) Received: from [10.33.1.105] (184-96-184-160.hlrn.qwest.net. [184.96.184.160]) by mx.google.com with ESMTPS id y9sm3442286igm.10.2012.10.06.10.05.36 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 06 Oct 2012 10:05:37 -0700 (PDT) Date: Sat, 6 Oct 2012 11:05:36 -0600 From: David Miles To: "Bernie Volz (volz)" Message-ID: <88E3E8CADDC74D0E951283C31FAA2D19@pheynix.net> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E0F5271DD@xmb-rcd-x04.cisco.com> References: <20121006002120.GA22039@shell-too.nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F5271DD@xmb-rcd-x04.cisco.com> X-Mailer: sparrow 1.6.4 (build 1176) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Gm-Message-State: ALoCoQlMnoVQzjqKQTgH0JSfOUS0LCFLXsiIiPpkHQrwFZT8jgVdFZAvONneIE0/36QEW/5XWSHv Cc: "=?utf-8?Q?dhcwg=40ietf.org?=" Subject: Re: [dhcwg] DHCPv6 NoAddrAvailable 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, 06 Oct 2012 17:05:41 -0000 Bernie, my apologies, in reading 4.2 of draft-ietf-dhc-dhcpv6-stateful-issues-01 makes some proposal that seems reasonable. Additional text applicable to the Requesting Router may be useful to be clear that a RR should not ignore a Advertise with a Status Code 'NoAddrAvail' at the top level, but should instead examine for a IA_PD and any Status Code of NoPrefixAvail there before ignoring the Advertise message. Sorry mate , d From volz@cisco.com Sat Oct 6 12:54:40 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 691D421F8487 for ; Sat, 6 Oct 2012 12:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.492 X-Spam-Level: X-Spam-Status: No, score=-10.492 tagged_above=-999 required=5 tests=[AWL=0.107, 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 TOaLLfo52B2j for ; Sat, 6 Oct 2012 12:54:39 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE8B21F847B for ; Sat, 6 Oct 2012 12:54:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3798; q=dns/txt; s=iport; t=1349553279; x=1350762879; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=vBKV7+592B45RUMkQIwC8lWyXy2svPsTT5/ixBTDhyQ=; b=PkXgt/FIxViZuAE3cp9TZhpKjS0WHVSlk8IU28KSnGPSH/8ZLVj2Zl/j EVwPIdnmLh2+pxykYHJGnd9U/qdncr55rI46FeapmmOttRL7zLn5Vgej7 pZP1LkxBiNpdwCgrsr1Rcxk5XNTpJYFdl9DUTrsrpe2L3y0WglkU6h12N Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAIWLcFCtJV2Y/2dsb2JhbABFhhG4E3+BCIIgAQEBBBIBEBFFDAQCAQgRBAEBAQICBh0DAgICMBQBCAgCBA4FCBqHY5lrjRuSCYEhgSKJDIR+MmADpDCBaYJtghc X-IronPort-AV: E=Sophos;i="4.80,545,1344211200"; d="scan'208";a="129032771" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP; 06 Oct 2012 19:54:39 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q96Jsd5d013813 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 6 Oct 2012 19:54:39 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.200]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.001; Sat, 6 Oct 2012 14:54:38 -0500 From: "Bernie Volz (volz)" To: David Miles Thread-Topic: [dhcwg] DHCPv6 NoAddrAvailable Thread-Index: AQHNo0ybecTMmH+I0k60gxCF7L3bFpervjwA///NmJCAAUnoAP//2z2w Date: Sat, 6 Oct 2012 19:54:38 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E0F52D9CB@xmb-rcd-x04.cisco.com> References: <20121006002120.GA22039@shell-too.nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F5271DD@xmb-rcd-x04.cisco.com> <3DA1744868D7494E82766FBA8C916EAE@pheynix.net> In-Reply-To: <3DA1744868D7494E82766FBA8C916EAE@pheynix.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.254.148] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19246.000 x-tm-as-result: No--42.818600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] DHCPv6 NoAddrAvailable 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, 06 Oct 2012 19:54:40 -0000 VGhlIHN0YXRlZnVsLWlzc3VlcyBkcmFmdCBkb2Vzbid0IGFkZHJlc3MgdGhpcyAtIHdlIHNhaWQg aXQgd2FzIHRvIHJlbWFpbiB0aGUgc2FtZS4gVGhvdWdoIEkgZ3Vlc3MgdGhlIHF1ZXN0aW9uIGlz IHdoYXQgZG9lcyBpdCAndGhlIHNhbWUnIG1lYW4uIE15IGludGVycHJldGF0aW9uIG9mIFJGQyAz MzE1IGlzIGFwcGFyZW50bHkgZGlmZmVyZW50IHRoYW4gb3RoZXJzLg0KDQpJIHdpc2ggUkZDIDMz MTUgaGFkIHNhaWQgdG8gcHV0IHRoZSBzdGF0dXMgY29kZSBpbiBJQV8qIHN0YXR1cyBjb2RlcyBy ZWdhcmRsZXNzIG9mIHdoZXRoZXIgaXQgYXBwbGllcyB0byBhbGwgb3IganVzdCBvbmUgaW5kaXZp ZHVhbGx5IChJIGFyZ3VlZCBmb3IgdGhpcyBhdCB0aGUgdGltZSBidXQgbG9zdCBvdXQpIGJ1dCBp dCBkaWRuJ3QgYW5kIEkgdGhpbmsgaXQgaXMgYSBtYXR0ZXIgb2YgaW50ZXJwcmV0YXRpb24gYXMg dG8gd2hhdCBzaG91bGQgaGFwcGVuIGluIHRoZSBjYXNlIG9mIG1peGVkIElBX05BL0lBX1BELg0K DQpQZXJoYXBzIGNsaWVudHMgYWxyZWFkeSBkZWFsIHdpdGggdGhpcyBjYXNlIGFzIHRoZXJlIGFw cGVhciB0byBiZSAzIHNlcnZlcnMgdGhhdCBiZWhhdmUgZGlmZmVyZW50bHkgYW5kIHRoYXQgbWVh bnMgdGhhdCBjbGllbnRzIHdpbGwgd29yayByZWdhcmRsZXNzIG9mIHdoZXJlIHRoZSBvcHRpb25z IGFyZT8/DQoNCklmIHRoZXJlIGlzIHN1ZmZpY2llbnQgY29uc2Vuc3VzLCBpdCB3b3VsZCBiZSBn cmVhdCB0byBhZGQgdG8gdGhlIHN0YXRlZnVsLWlzc3VlcyBkcmFmdCB0aGF0IFJGQyAzMzE1IGlz IGNoYW5nZWQgdG8gcHV0IHRoZSBOb0FkZHJzQXZhaWwgc3RhdHVzIGNvZGUgaW4gdGhlIElBXyog aXRzZWxmIGFuZCBub3QgaW4gdGhlIHRvcCBsZXZlbCBvcHRpb24uDQoNCi0gQmVybmllDQoNCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBEYXZpZCBNaWxlcyBbbWFpbHRvOmRhdmlk QHBoZXluaXgubmV0XSANClNlbnQ6IFNhdHVyZGF5LCBPY3RvYmVyIDA2LCAyMDEyIDE6MDIgUE0N ClRvOiBCZXJuaWUgVm9seiAodm9seikNCkNjOiBTdGVwaGVuIEphY29iOyBkaGN3Z0BpZXRmLm9y Zw0KU3ViamVjdDogUmU6IFtkaGN3Z10gREhDUHY2IE5vQWRkckF2YWlsYWJsZQ0KDQpPbiBGcmlk YXksIE9jdG9iZXIgNSwgMjAxMiBhdCA4OjI4IFBNLCBCZXJuaWUgVm9seiAodm9seikgd3JvdGU6 DQo+IEFjdHVhbGx5LCB0aGUgY29ycmVjdCBhbnN3ZXIgc2hvdWxkIGJlOg0KPiAgDQo+IFNlcnZl ciBDOi0NCj4gQWR2ZXJ0aXNlDQo+IENsaWVudC1JZA0KPiBTZXJ2ZXItSWQNCj4gSUFfUEQNCj4g ICBTdGF0dXMgQ29kZTogTm9QcmVmaXhBdmFpbA0KPiBTdGF0dXMgQ29kZTogTm9BZGRyc0F2YWls DQo+ICANCkJlcm5pZSwgIA0KDQp0aGFua3MgZm9yIHRoZSBleGFtcGxlLiBTbyBpbiB0aGUgbWl4 ZWQgY2FzZSAoc29tZSBJQSBoYXZlIGFkZHJlc3Nlcy9wcmVmaXhlcyBhbmQgb3RoZXJzIGRvbid0 KSBhbmQgdHJ5aW5nIHRvIHJlbWFpbiBjb21wbGlhbnQgd2l0aCBzZWN0aW9uIDE4LjEuODoNCg0K VGhlIGNsaWVudCBleGFtaW5lcyB0aGUgc3RhdHVzIGNvZGUgaW4gZWFjaCBJQSBpbmRpdmlkdWFs bHkuIElmIHRoZSBzdGF0dXMgY29kZSBpcyBOb0FkZHJzQXZhaWwsIHRoZSBjbGllbnQgaGFzIHJl Y2VpdmVkIG5vIHVzYWJsZSBhZGRyZXNzZXMgaW4gdGhlIElBIGFuZCBtYXkgY2hvb3NlIHRvIHRy eSBvYnRhaW5pbmcgYWRkcmVzc2VzIGZvciB0aGUgSUEgZnJvbSBhbm90aGVyIHNlcnZlci4NCg0K SXQgc3VnZ2VzdHMgdGhhdCB3aGVuIHRoZXJlIGlzIGEgbXVsdGlwbGUgSUEgY29tYmluYXRpb24g d2l0aCBkaWZmZXJpbmcgbGV2ZWxzIG9mIHN1Y2Nlc3MsIHRoZW4gdGhlIHN0YXR1cyBjb2RlIG11 c3QgYWx3YXlzIGJlIGluIHRoZSBJQT8NCg0KQnkgcHV0dGluZyB0aGUgU3RhdHVzIENvZGUgTm9B ZGRyQXZhaWxhYmxlIGF0IHRoZSAndG9wJyBsZXZlbCB0aGVuIHRoZSB0ZXh0IG9mIDE3LjEuMyBb VGhlIGNsaWVudCBNVVNUIGlnbm9yZSBhbnkgQWR2ZXJ0aXNlIG1lc3NhZ2UgdGhhdCBpbmNsdWRl cyBhIFN0YXR1cyBDb2RlIG9wdGlvbiBjb250YWluaW5nIHRoZSB2YWx1ZSBOb0FkZHJzQXZhaWws IHdpdGggdGhlIGV4Y2VwdGlvbiB0aGF0IHRoZSBjbGllbnQgTUFZIGRpc3BsYXkgdGhlIGFzc29j aWF0ZWQgc3RhdHVzIG1lc3NhZ2UgdG8gdGhlIHVzZXIuXSwgIGl0IHNlZW1zIGEgc2VydmVyIE1V U1QgTk9UIHB1dCBhIHN0YXR1cyBjb2RlIGF0IHRoZSB0b3AgbGV2ZWwgdW5sZXNzIGFsbCBJQSBo YXZlIE5vQWRkckF2YWlsIGFuZCBOb1ByZWZpeGVzQXZhaWwuIEluIHRoZSBjYXNlcyB3aGVyZSB0 aGVyZSBhcmUgbWl4ZWQgcmVzdWx0cyB0aGUgc3RhdHVzIGNvZGVzIHNob3VsZCBiZSB3aXRoaW4g dGhlIGFwcHJvcHJpYXRlIElBPw0KDQpQZXJoYXBzIHRoaXMgaXMgd2hlcmUgdGhlIGNvbmZ1c2lv biBpcywgYXMgaXQgaXMgbm90IGV4cGxpY2l0IHRoYXQgYW4gQWR2ZXJ0aXNlIGluIHdoaWNoIElB IGhhdmUgbWl4ZWQgcmVzdWx0cy9zdGF0dXMgY29kZXMgc2hvdWxkIGVtcGxveSB0aG9zZSBzdGF0 dXMgY29kZXMgYXQgdGhlIElBIGxldmVsLiBJIGFwcHJlY2lhdGUgaXQgd2Fzbid0IG15IHF1ZXN0 aW9uLCBidXQgSSB3YW50ZWQgdG8gYmUgc3VyZSB0aGlzIGNvcm5lciBjYXNlIGRpZG4ndCBjaGFu Z2UgYW55IG9mIHRoZSBzdWdnZXN0ZWQgYmVzdCBwcmFjdGljZSB3b3JrIMOYbGUgYW5kIHlvdSBh cmUgd29ya2luZyBvbi4NCg0KY2hlZXJzIGFnYWluDQoNCmQNCg== From leaf.y.yeh@huawei.com Sun Oct 7 21:12:01 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9841521F8762 for ; Sun, 7 Oct 2012 21:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 Y+lAknxU-GtI for ; Sun, 7 Oct 2012 21:12:01 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7DCE421F875E for ; Sun, 7 Oct 2012 21:12:00 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKJ72459; Mon, 08 Oct 2012 04:11:59 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 8 Oct 2012 05:11:35 +0100 Received: from SZXEML422-HUB.china.huawei.com (10.82.67.161) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 8 Oct 2012 05:11:58 +0100 Received: from SZXEML546-MBX.china.huawei.com ([169.254.3.192]) by szxeml422-hub.china.huawei.com ([10.82.67.161]) with mapi id 14.01.0323.003; Mon, 8 Oct 2012 12:11:50 +0800 From: Leaf yeh To: Ted Lemon , Tomek Mrugalski Thread-Topic: [dhcwg] Call for adoption: draft-mrugalski-softwire-dhcpv4-over-v6-option-01 Thread-Index: AQHNoy/3x07iyqI+M0+SYXbfMix6M5eusfZw Date: Mon, 8 Oct 2012 04:11:50 +0000 Message-ID: References: <93BA6FCE-4EAF-4F56-9E4F-B6E389834A41@nominum.com> In-Reply-To: <93BA6FCE-4EAF-4F56-9E4F-B6E389834A41@nominum.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.83.152] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: dhcwg WG Subject: Re: [dhcwg] Call for adoption: draft-mrugalski-softwire-dhcpv4-over-v6-option-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, 08 Oct 2012 04:12:01 -0000 a. Schedule question: draft-mrugalski-softwire-dhcpv4-over-v6-option sounds= work for the draft-cui-softwire-b4-translated-ds-lite per the section 2 of= introduction, but draft-cui (LW4o6) is still in the status of individual d= raft. Is it suitable to adopt this draft after the (softwire) adoption of d= raft-cui? In a typical deployment as [I-D.cui-softwire-b4-translated-ds-lite].= .., CRA functionality will be a part of a Lightweight B4 element (Basic Bri= dging BroadBand element) implementation. ...the typical envisaged use would be the Lightweight 4over6 archite= cture, where TSV or TRA could be part of Lightweight AFTR implementation. The above is quoted as the reference. b. A naive question on the network scenario: why do we need call the client= (LW4o6 initiator) to be CRA, not the *client* directly? c. One more naive question on the network scenario: Could the dhcp4ov6 endp= oint (called TSV or TRA) be the different one with the LW4o6 tunnel endpoin= t (called LW4o6 concentrator)? If yes, not sure it have been mentioned in d= raft-cui. d. Technical question: Section 5 - DHCPv6 Client Behavior - It SHOUL= D warn its operator about such condition.. How? Best Regards, Leaf -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= ed Lemon Sent: Saturday, October 06, 2012 3:31 AM To: dhcwg WG Subject: Re: [dhcwg] Call for adoption: draft-mrugalski-softwire-dhcpv4-ove= r-v6-option-01 On Sep 26, 2012, at 1:27 PM, Ted Lemon wrote: > The authors have requested that the working group adopt draft-mrugalski-s= oftwire-dhcpv4-over-v6-option as a working group work item. The document = is within the scope of the current charter. It describes a DHCPv6 option = that is used to configure client relay agents (draft-ietf-dhc-dhcpv4-over-i= pv6). Just a reminder: we have only seen two responses on this draft, and I know = that there are more than two working group participants who are interested = in it. The call for adoption expires on October 10. FTR, with my wg chair hat off, I'm in favor of adopting. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From Ted.Lemon@nominum.com Mon Oct 8 04:22:52 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D82221F871E for ; Mon, 8 Oct 2012 04:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.47 X-Spam-Level: X-Spam-Status: No, score=-106.47 tagged_above=-999 required=5 tests=[AWL=0.129, 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 NgBBguZwyIZ1 for ; Mon, 8 Oct 2012 04:22:51 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id 35CB121F86B7 for ; Mon, 8 Oct 2012 04:22:51 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKUHK3iqh2y4pNt1Q5EyaM7nojPG7OHLpA@postini.com; Mon, 08 Oct 2012 04:22:51 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 2E50D1B8315 for ; Mon, 8 Oct 2012 04:22:50 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 1F7D319005C; Mon, 8 Oct 2012 04:22:50 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Mon, 8 Oct 2012 04:22:44 -0700 From: Ted Lemon To: Leaf yeh Thread-Topic: [dhcwg] Call for adoption: draft-mrugalski-softwire-dhcpv4-over-v6-option-01 Thread-Index: AQHNpQsUHRuQdiKJx0iDvIP+Vk1kdpevubsA Date: Mon, 8 Oct 2012 11:22:44 +0000 Message-ID: <49EED9B7-DEA6-453D-9BDA-90FBD69E5583@nominum.com> References: <93BA6FCE-4EAF-4F56-9E4F-B6E389834A41@nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <1AA4A492CE07EA4483C6285C04A12428@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dhcwg WG Subject: Re: [dhcwg] Call for adoption: draft-mrugalski-softwire-dhcpv4-over-v6-option-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, 08 Oct 2012 11:22:52 -0000 On Oct 8, 2012, at 12:11 AM, Leaf yeh wrote: > a. Schedule question: draft-mrugalski-softwire-dhcpv4-over-v6-option soun= ds work for the draft-cui-softwire-b4-translated-ds-lite per the section 2 = of introduction, but draft-cui (LW4o6) is still in the status of individual= draft. Is it suitable to adopt this draft after the (softwire) adoption of= draft-cui? No, it's actually for the dhcpv4-over-ipv6 draft. From leaf.y.yeh@huawei.com Mon Oct 8 04:47:14 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DADD421F86A2 for ; Mon, 8 Oct 2012 04:47:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.472 X-Spam-Level: X-Spam-Status: No, score=-6.472 tagged_above=-999 required=5 tests=[AWL=0.127, 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 BhpaOTo0JByn for ; Mon, 8 Oct 2012 04:47:14 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C80FB21F8682 for ; Mon, 8 Oct 2012 04:47:13 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALK75151; Mon, 08 Oct 2012 11:47:12 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 8 Oct 2012 12:46:47 +0100 Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 8 Oct 2012 12:47:10 +0100 Received: from SZXEML546-MBX.china.huawei.com ([169.254.3.192]) by szxeml401-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Mon, 8 Oct 2012 19:47:06 +0800 From: Leaf yeh To: Ted Lemon Thread-Topic: [dhcwg] Call for adoption: draft-mrugalski-softwire-dhcpv4-over-v6-option-01 Thread-Index: AQHNpUdE1En6rtdqTkKv1iA5SdwRyJevSc5w Date: Mon, 8 Oct 2012 11:47:05 +0000 Message-ID: References: <93BA6FCE-4EAF-4F56-9E4F-B6E389834A41@nominum.com> <49EED9B7-DEA6-453D-9BDA-90FBD69E5583@nominum.com> In-Reply-To: <49EED9B7-DEA6-453D-9BDA-90FBD69E5583@nominum.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.83.152] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: dhcwg WG Subject: Re: [dhcwg] Call for adoption: draft-mrugalski-softwire-dhcpv4-over-v6-option-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, 08 Oct 2012 11:47:15 -0000 A supplement or an update to draft-ietf-dhc-dhcpv4-over-ipv6? Best Regards, Leaf -----Original Message----- From: Ted Lemon [mailto:Ted.Lemon@nominum.com]=20 Sent: Monday, October 08, 2012 7:23 PM To: Leaf yeh Cc: Tomek Mrugalski; dhcwg WG Subject: Re: [dhcwg] Call for adoption: draft-mrugalski-softwire-dhcpv4-ove= r-v6-option-01 On Oct 8, 2012, at 12:11 AM, Leaf yeh wrote: > a. Schedule question: draft-mrugalski-softwire-dhcpv4-over-v6-option soun= ds work for the draft-cui-softwire-b4-translated-ds-lite per the section 2 = of introduction, but draft-cui (LW4o6) is still in the status of individual= draft. Is it suitable to adopt this draft after the (softwire) adoption of= draft-cui? No, it's actually for the dhcpv4-over-ipv6 draft. From david@pheynix.net Mon Oct 8 09:03:39 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B16CD21F859B for ; Mon, 8 Oct 2012 09:03:39 -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 bKr7mEKjOcVS for ; Mon, 8 Oct 2012 09:03:38 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9239A21F8567 for ; Mon, 8 Oct 2012 09:03:38 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so11133353iec.31 for ; Mon, 08 Oct 2012 09:03:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pheynix.net; s=google; h=date:from:to:cc:message-id:in-reply-to:references:subject:x-mailer :mime-version:content-type:content-transfer-encoding :content-disposition; bh=izHOGk1zvIVdWS/DypzlxZpi5nF+Vpq2UHCzYMvLSdk=; b=YRETdk91LwHhVr5OaXIoz7dWNXBDLvjvYdZB521ZI7S7ASSb1HL/hhoJcRbmt1Qno9 /cTEJGgodmQCVRhd24og9uIdfdCF3Y3l08nG6fiNg/kJt+GP7GIFVa7RFsAhwdqIOmeu h09AZS9lvFAQOpZVpdwT5AuN8Uu3hOahiUBGE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject:x-mailer :mime-version:content-type:content-transfer-encoding :content-disposition:x-gm-message-state; bh=izHOGk1zvIVdWS/DypzlxZpi5nF+Vpq2UHCzYMvLSdk=; b=e7qg6WW/Lh0o3xLq5DS5q3Wd4zxLPtMhU30WEO+XyzI5E8PtlTEPkIAMrqCHkGWdhb gr3Nv8ZVwzJY0QHPLT+XuI0voIdwwRdCjYc+aod5Ixn1ABNVrXr0byGX4zO/OUdLALxa b8+pCvgw7Vfv8DwmFC/gx+KQV2RHaXkP/PIZvdAi4ihvY+RNfvCfm/paRh20hHptZzOC GEU9I1FwBHar3KEBjsrzFzS99im8PHjTbNX+Pagqp9lJT060qQnrODwaAU4bYa2HTMl9 dSEKOAo5hPErBvyRxhRob4rcE9xxGXyqNNHLinJkJqa7Eu+gHvqoorngh22X1iafXxXv 8UEQ== Received: by 10.50.185.231 with SMTP id ff7mr8826282igc.40.1349712218181; Mon, 08 Oct 2012 09:03:38 -0700 (PDT) Received: from [192.168.1.132] ([67.40.49.164]) by mx.google.com with ESMTPS id y9sm7711167igm.10.2012.10.08.09.03.36 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 08 Oct 2012 09:03:37 -0700 (PDT) Date: Mon, 8 Oct 2012 10:03:32 -0600 From: David Miles To: "Bernie Volz (volz)" Message-ID: <7CA284C552BB4D41BA253733B5A1FE9F@pheynix.net> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E0F52D9CB@xmb-rcd-x04.cisco.com> References: <20121006002120.GA22039@shell-too.nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F5271DD@xmb-rcd-x04.cisco.com> <3DA1744868D7494E82766FBA8C916EAE@pheynix.net> <489D13FBFA9B3E41812EA89F188F018E0F52D9CB@xmb-rcd-x04.cisco.com> X-Mailer: sparrow 1.6.4 (build 1176) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Gm-Message-State: ALoCoQlZF/nr69ae3lsTnMMScyP2HsvKJOjqHsjRDs0D6w1b2ORiSlSPK+COEVwUw/5g98p+bdvw Cc: =?utf-8?Q?Ole_Tr=C3=B8an?= , "=?utf-8?Q?dhcwg=40ietf.org?=" Subject: Re: [dhcwg] DHCPv6 NoAddrAvailable 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, 08 Oct 2012 16:03:39 -0000 > > I wish RFC 3315 had said to put the status code in IA_* status codes regardless of whether it applies to all or just one individually (I argued for this at the time but lost out) but it didn't and I think it is a matter of interpretation as to what should happen in the case of mixed IA_NA/IA_PD. > I too would see that as the most ideal implementation, as right now it seems a requesting router must treat any 'top' level NoAddrAvail as only an indicator for the IA_NA and not for PD. Regardless of the approach taken, I think clarifying text is worthwhile. > > Perhaps clients already deal with this case as there appear to be 3 servers that behave differently and that means that clients will work regardless of where the options are?? Well, my problem is right now the client isn't dealing with some of the servers. If a vendor is going to make changes to get interop working I'd like to suggest the "right" way as well as including these 3 other ways so that it may be compatible. Any of the ISC guys able to shed light on how ISC dhcpd would handle these situations for another point of ref? > > If there is sufficient consensus, it would be great to add to the stateful-issues draft that RFC 3315 is changed to put the NoAddrsAvail status code in the IA_* itself and not in the top level option. > I would place my vote there, agreeing with your earlier statement that it was written when the IA_NA/TA were the only IA types, now we have IA_PD (and perhaps more later) it seems more extensible to put NoAddrAvail in the IA itself. Putting NoAddrAvailable at the top-level to indicate that there are no addresses and prefixes seems wrong (as i don't think NoAddrAvail should imply no prefixes as well). I'd suggest text along the lines of: - A server generating an Advertise MUST put any status codes under the appropriate IA - A client MUST check each present IA. Any IA_NA/TA that have a status code of NoAddrAvailable and any IA_PD that have a status code of NoPrefixesAvailable must be ignored (and no request sent for that IA). If all IA were unavail then the client MUST ignore the Advertise. - In the absence of any IA and the presence of a status-code of NoAddrAvail the client MUST ignore the Advertise. From Stephen.Jacob@nominum.com Mon Oct 8 11:11:23 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82DDD21F87CA for ; Mon, 8 Oct 2012 11:11:23 -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 rf5VvO5ldkIv for ; Mon, 8 Oct 2012 11:11:22 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by ietfa.amsl.com (Postfix) with ESMTP id E7F9C21F87C7 for ; Mon, 8 Oct 2012 11:11:21 -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 DSNKUHMXSBW+vUBV0fYPm/maVlLg4hfDMPWT@postini.com; Mon, 08 Oct 2012 11:11:22 PDT Received: by shell-too.nominum.com (Postfix, from userid 11053) id 856FF1B82E3; Mon, 8 Oct 2012 11:11:20 -0700 (PDT) Date: Mon, 8 Oct 2012 11:11:20 -0700 From: Stephen Jacob To: "Bernie Volz (volz)" Message-ID: <20121008181120.GA29839@shell-too.nominum.com> Mail-Followup-To: "Bernie Volz (volz)" , David Miles , Stephen Jacob , "dhcwg@ietf.org" References: <20121006002120.GA22039@shell-too.nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F5271DD@xmb-rcd-x04.cisco.com> <3DA1744868D7494E82766FBA8C916EAE@pheynix.net> <489D13FBFA9B3E41812EA89F188F018E0F52D9CB@xmb-rcd-x04.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E0F52D9CB@xmb-rcd-x04.cisco.com> User-Agent: Mutt/1.4.2.2i X-URI: http://www.nominum.com/ Organization: Nominum, Inc. Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] DHCPv6 NoAddrAvailable 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, 08 Oct 2012 18:11:23 -0000 On Sat, Oct 06, 2012 at 07:54:38PM +0000, Bernie Volz (volz) wrote: > If there is sufficient consensus, it would be great to add to the > stateful-issues draft that RFC 3315 is changed to put the NoAddrsAvail > status code in the IA_* itself and not in the top level option. I think I've already made it clear that I'd like this. :) Perhaps a backwards-compatible way to go might be that servers: - MUST put the NoAddrsAvail status code in the IA_* itself, and - SHOULD put the NoAddrsAvail status code at the top level The latter for backwards compatibility with clients that expect it to be there. Clients complying to the new standard could ignore the top level, with ambiguity removed by each IA_* having a status associated with it. Would that be an acceptable solution? Regards, Stephen -- Stephen Jacob | Stephen.Jacob@nominum.com | +1 650 381 6051 Nominum, Inc. | http://www.nominum.com/ | +1 650 381 6000 From Ted.Lemon@nominum.com Mon Oct 8 11:42:28 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CB4121F8835 for ; Mon, 8 Oct 2012 11:42:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.475 X-Spam-Level: X-Spam-Status: No, score=-106.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 I1XWHMnEW+y1 for ; Mon, 8 Oct 2012 11:42:27 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id 7354721F881B for ; Mon, 8 Oct 2012 11:42:27 -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 DSNKUHMek2eBOkdhWI5suOFQHt4LfLotYNHD@postini.com; Mon, 08 Oct 2012 11:42:27 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 A800C1B82FE for ; Mon, 8 Oct 2012 11:42:26 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 9D7B819005D; Mon, 8 Oct 2012 11:42:26 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Mon, 8 Oct 2012 11:42:26 -0700 From: Ted Lemon To: Stephen Jacob Thread-Topic: [dhcwg] DHCPv6 NoAddrAvailable Thread-Index: AQHNo0yaYo/DVJ/IuE2RTI87N1YB2per38MAgAAjdwCAAPQJAIAAMFEAgAMHzQCAAAiwgA== Date: Mon, 8 Oct 2012 18:42:25 +0000 Message-ID: <3BB803F8-F05F-47AA-9708-44E4A1A9C05D@nominum.com> References: <20121006002120.GA22039@shell-too.nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F5271DD@xmb-rcd-x04.cisco.com> <3DA1744868D7494E82766FBA8C916EAE@pheynix.net> <489D13FBFA9B3E41812EA89F188F018E0F52D9CB@xmb-rcd-x04.cisco.com> <20121008181120.GA29839@shell-too.nominum.com> In-Reply-To: <20121008181120.GA29839@shell-too.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <01A6198C51FFEB4F848F147CDEE99B44@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , "Bernie Volz \(volz\)" Subject: Re: [dhcwg] DHCPv6 NoAddrAvailable 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, 08 Oct 2012 18:42:28 -0000 On Oct 8, 2012, at 2:11 PM, Stephen Jacob wrote: > Would that be an acceptable solution? Seems like a kludge=97maybe it's necessary, but it's worth examining. Wha= t's the downside to not sending NoAddrsAvail in the global scope? From twinters@iol.unh.edu Mon Oct 8 17:46:06 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA701F0C88 for ; Mon, 8 Oct 2012 17:46:06 -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 cr17oBmu9aiw for ; Mon, 8 Oct 2012 17:46:05 -0700 (PDT) Received: from exprod5og105.obsmtp.com (exprod5og105.obsmtp.com [64.18.0.180]) by ietfa.amsl.com (Postfix) with SMTP id D92511F0C7E for ; Mon, 8 Oct 2012 17:46:03 -0700 (PDT) Received: from postal.iol.unh.edu ([132.177.123.84]) by exprod5ob105.postini.com ([64.18.4.12]) with SMTP ID DSNKUHNzy8OprHHk8Tzr+46kN4DZS6CBnDjB@postini.com; Mon, 08 Oct 2012 17:46:05 PDT Received: from openvpn-client4.iol.unh.edu (openvpn-client4.iol.unh.edu [132.177.124.194]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by postal.iol.unh.edu (Postfix) with ESMTPSA id 11B3E8F007C; Mon, 8 Oct 2012 20:46:00 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Timothy Winters In-Reply-To: <3BB803F8-F05F-47AA-9708-44E4A1A9C05D@nominum.com> Date: Mon, 8 Oct 2012 20:46:00 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121006002120.GA22039@shell-too.nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F5271DD@xmb-rcd-x04.cisco.com> <3DA1744868D7494E82766FBA8C916EAE@pheynix.net> <489D13FBFA9B3E41812EA89F188F018E0F52D9CB@xmb-rcd-x04.cisco.com> <20121008181120.GA29839@shell-too.nominum.com> <3BB803F8-F05F-47AA-9708-44E4A1A9C05D@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1499) Cc: "dhcwg@ietf.org" , "Bernie Volz \(volz\)" Subject: Re: [dhcwg] DHCPv6 NoAddrAvailable 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, 09 Oct 2012 00:46:06 -0000 Hi Ted, We've seen DHCP Clients not properly handle the status code in = the IA_NA option. Basically older clients that are only looking for = it in the global scope and regrettable accept the IA_NA when the status = code NoAddrsAvail is in the IA_NA. We not seen this behavior for the = IA_PD, but that behavior was clearly defined in 3633. Regards, Tim On Oct 8, 2012, at 2:42 PM, Ted Lemon wrote: > On Oct 8, 2012, at 2:11 PM, Stephen Jacob > wrote: >> Would that be an acceptable solution? >=20 > Seems like a kludge=97maybe it's necessary, but it's worth examining. = What's the downside to not sending NoAddrsAvail in the global scope? >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From volz@cisco.com Mon Oct 8 17:51:30 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54EA41F0C88 for ; Mon, 8 Oct 2012 17:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AfZHc5GcvKif for ; Mon, 8 Oct 2012 17:51:28 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id DFC0B1F0C8E for ; Mon, 8 Oct 2012 17:51:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1862; q=dns/txt; s=iport; t=1349743888; x=1350953488; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=3r8gxo/9gIaaB9h2+BNPdpe6ShvQN6hljclv6er/d04=; b=JS8jmVwI/mEMrsfUdCtKWkzV54aOFNdrdDh2vusyF4dF17CP9tX9U5Vn V/aFxV8T6pi2J9NiQUrcsgBkmRlM1A6jtbI3eSJtxjUpK+ZGwdEH5Deoq 56Kr9lSLmzMAMDlwdrvy49R0IElm3fFQYMAqCDWcYTp4dFQVF014KGnyq A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAFR0c1CtJXHB/2dsb2JhbABFDr8kgQiCIAEBAQMBAQEBDwEnNAsFBwQCAQgOAwQBAQEKFAkHJwsUCQgCBAENBQgTB4ddBguaS49WkCoEgkOJBIUzYAOkMIFpgjI7ghc X-IronPort-AV: E=Sophos;i="4.80,556,1344211200"; d="scan'208";a="129556843" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-7.cisco.com with ESMTP; 09 Oct 2012 00:51:27 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q990pRYP021957 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Oct 2012 00:51:27 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.200]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.001; Mon, 8 Oct 2012 19:51:27 -0500 From: "Bernie Volz (volz)" To: Timothy Winters , Ted Lemon Thread-Topic: [dhcwg] DHCPv6 NoAddrAvailable Thread-Index: AQHNo0ybecTMmH+I0k60gxCF7L3bFpervjwA///NmJCAAUnoAP//2z2wgAN3YJGAAAA0UA== Date: Tue, 9 Oct 2012 00:51:27 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E0F5375CD@xmb-rcd-x04.cisco.com> References: <20121006002120.GA22039@shell-too.nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F5271DD@xmb-rcd-x04.cisco.com> <3DA1744868D7494E82766FBA8C916EAE@pheynix.net> <489D13FBFA9B3E41812EA89F188F018E0F52D9CB@xmb-rcd-x04.cisco.com> <20121008181120.GA29839@shell-too.nominum.com> <3BB803F8-F05F-47AA-9708-44E4A1A9C05D@nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.247.54] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19252.004 x-tm-as-result: No--43.423900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] DHCPv6 NoAddrAvailable 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, 09 Oct 2012 00:51:30 -0000 That's a bit of useful information. I think the USG DHCPv6 tests must test = this behavior for clients and servers? Though not sure whether they test wh= at happens at the client if the wrong answer is given by the server? And, n= ot sure how many implementations have had that testing. I'm much more in favor of documenting the existing behavior and living with= it (as I think that breaks fewer things). It isn't optimum, but in the end= it really doesn't matter as long as implementers understand what is expect= ed. And today that isn't as clear as it needs to be. Perhaps the stateful issues draft can expand on this and clarify the server= 's answer (using the example of what the returned message should look like)= . - Bernie -----Original Message----- From: Timothy Winters [mailto:twinters@iol.unh.edu]=20 Sent: Monday, October 08, 2012 8:46 PM To: Ted Lemon Cc: Stephen Jacob; dhcwg@ietf.org; Bernie Volz (volz) Subject: Re: [dhcwg] DHCPv6 NoAddrAvailable Hi Ted, We've seen DHCP Clients not properly handle the status code in the IA_NA o= ption. Basically older clients that are only looking for it in the globa= l scope and regrettable accept the IA_NA when the status code NoAddrsAvail = is in the IA_NA. We not seen this behavior for the IA_PD, but that behavi= or was clearly defined in 3633. Regards, Tim On Oct 8, 2012, at 2:42 PM, Ted Lemon wrote: > On Oct 8, 2012, at 2:11 PM, Stephen Jacob > wrote: >> Would that be an acceptable solution? >=20 > Seems like a kludge-maybe it's necessary, but it's worth examining. Wha= t's the downside to not sending NoAddrsAvail in the global scope? >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From Ted.Lemon@nominum.com Mon Oct 8 18:37:08 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AFDD21F8596 for ; Mon, 8 Oct 2012 18:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.477 X-Spam-Level: X-Spam-Status: No, score=-106.477 tagged_above=-999 required=5 tests=[AWL=0.122, 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 NEapZTrF++p8 for ; Mon, 8 Oct 2012 18:37:07 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id ACD8121F8589 for ; Mon, 8 Oct 2012 18:37:07 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKUHN/w1+2DB05DMLiWAr6If1pfnqoVlfy@postini.com; Mon, 08 Oct 2012 18:37:07 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 AD99D1B82E3 for ; Mon, 8 Oct 2012 18:37:06 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id A300819005C; Mon, 8 Oct 2012 18:37:06 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Mon, 8 Oct 2012 18:37:06 -0700 From: Ted Lemon To: "Bernie Volz (volz)" Thread-Topic: [dhcwg] DHCPv6 NoAddrAvailable Thread-Index: AQHNo0yaYo/DVJ/IuE2RTI87N1YB2per38MAgAAjdwCAAPQJAIAAMFEAgAMHzQCAAAiwgIAAZZUAgAABhoCAAAzBAA== Date: Tue, 9 Oct 2012 01:37:06 +0000 Message-ID: References: <20121006002120.GA22039@shell-too.nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F5271DD@xmb-rcd-x04.cisco.com> <3DA1744868D7494E82766FBA8C916EAE@pheynix.net> <489D13FBFA9B3E41812EA89F188F018E0F52D9CB@xmb-rcd-x04.cisco.com> <20121008181120.GA29839@shell-too.nominum.com> <3BB803F8-F05F-47AA-9708-44E4A1A9C05D@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F5375CD@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E0F5375CD@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] DHCPv6 NoAddrAvailable 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, 09 Oct 2012 01:37:08 -0000 On Oct 8, 2012, at 8:51 PM, "Bernie Volz (volz)" wrote: > I'm much more in favor of documenting the existing behavior and living wi= th it (as I think that breaks fewer things). It isn't optimum, but in the e= nd it really doesn't matter as long as implementers understand what is expe= cted. And today that isn't as clear as it needs to be. >=20 > Perhaps the stateful issues draft can expand on this and clarify the serv= er's answer (using the example of what the returned message should look lik= e). That sounds right. It's not how we would have done it if we'd anticipated= prefix delegation when we did 3315, but that's water under the bridge. From david@pheynix.net Mon Oct 8 21:27:14 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33DDF21F86D1 for ; Mon, 8 Oct 2012 21:27: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 SZ9MTO-xkvLi for ; Mon, 8 Oct 2012 21:27:13 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 77BA421F86D0 for ; Mon, 8 Oct 2012 21:27:13 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so12432912iec.31 for ; Mon, 08 Oct 2012 21:27:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pheynix.net; s=google; h=date:from:to:cc:message-id:in-reply-to:references:subject:x-mailer :mime-version:content-type:content-transfer-encoding :content-disposition; bh=i8r6zFsBTVUjmGl0XcyQIgqrYZdBtPEDtHxqFEucwkg=; b=nhQBxo1nfcI+cjo4BFDAeKyvbUfhptBFtbNOyzXBXuisNE0nIMaX0uW26zS1WL2VG8 oXMuXUv1vD8JKRg3VPjR75H5UQuV/HObeA8YacDhz6ZkJLDvXGe/69QP22CmexLOtI0i JiQHq8mioKVC0aHxqpxGTCelnW3rQRF0kMsxQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject:x-mailer :mime-version:content-type:content-transfer-encoding :content-disposition:x-gm-message-state; bh=i8r6zFsBTVUjmGl0XcyQIgqrYZdBtPEDtHxqFEucwkg=; b=Jcmdsb8DqnMqUtUv1JUzu+OfOtVACFLhiA5FVTtZ42NyaRPQxFwGXoTEHpWsQ3/7Mt NFWaaWD+YGYIZr+ufowzqoICHijNBzlYi8QTuFwcyvZPG5lqZNIhI++Uw8d2eXm9DZ5U fxW6gKTsvPK1a2nANQloSBxd9AgTna9U/XDpxL67e0h3AYZrhHlXO69HdQzad5derFi4 IlYUajaxPIN0A98QgLHM+WWCQ0twr3zFHxkXI/PGPVQuWnKfvxu0WcbWRdc4Ll1HytaO JYc0pmJcQBW97pNTIRwnVDF8W/KIVvDMHsVmzp+xfWODxzi2AQrYFP8seF+Q9f7YX5n9 bF8g== Received: by 10.50.36.133 with SMTP id q5mr520297igj.14.1349756833025; Mon, 08 Oct 2012 21:27:13 -0700 (PDT) Received: from [10.33.1.103] (184-96-184-160.hlrn.qwest.net. [184.96.184.160]) by mx.google.com with ESMTPS id i2sm8457229igl.8.2012.10.08.21.27.11 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 08 Oct 2012 21:27:12 -0700 (PDT) Date: Mon, 8 Oct 2012 22:27:13 -0600 From: David Miles To: Ted Lemon Message-ID: <964D3117423A4531920C5D9F9A89810D@pheynix.net> In-Reply-To: References: <20121006002120.GA22039@shell-too.nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F5271DD@xmb-rcd-x04.cisco.com> <3DA1744868D7494E82766FBA8C916EAE@pheynix.net> <489D13FBFA9B3E41812EA89F188F018E0F52D9CB@xmb-rcd-x04.cisco.com> <20121008181120.GA29839@shell-too.nominum.com> <3BB803F8-F05F-47AA-9708-44E4A1A9C05D@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F5375CD@xmb-rcd-x04.cisco.com> X-Mailer: sparrow 1.6.4 (build 1176) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Gm-Message-State: ALoCoQkX9EQ4SDsTiD2sqgVCZREMY9P7CG7+L4b2c8NHrnfk8OcvwTUA/QdBx8faWS5OHIkMr3zq Cc: "=?utf-8?Q?dhcwg=40ietf.org?=" , "Bernie Volz \(volz\)" Subject: Re: [dhcwg] DHCPv6 NoAddrAvailable 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, 09 Oct 2012 04:27:14 -0000 So back to status code for the IA_NA at 'top' level and IA_PD in the IA itself? I do think we need to some clarifying text so that be no suggestion that a client can just look at the IA_NA at the top level without checking for any IA_PD (provided the client is also a RR), and that an status code of NoAddrAvailable at the top level refers only to IA_NA/TA. d On Monday, October 8, 2012 at 7:37 PM, Ted Lemon wrote: > On Oct 8, 2012, at 8:51 PM, "Bernie Volz (volz)" > wrote: > > I'm much more in favor of documenting the existing behavior and living with it (as I think that breaks fewer things). It isn't optimum, but in the end it really doesn't matter as long as implementers understand what is expected. And today that isn't as clear as it needs to be. > > > > Perhaps the stateful issues draft can expand on this and clarify the server's answer (using the example of what the returned message should look like). > > That sounds right. It's not how we would have done it if we'd anticipated prefix delegation when we did 3315, but that's water under the bridge From ghalwasi@cisco.com Mon Oct 8 21:45:35 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9C2221F869A for ; Mon, 8 Oct 2012 21:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.072 X-Spam-Level: X-Spam-Status: No, score=-10.072 tagged_above=-999 required=5 tests=[AWL=0.527, 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 MoGwK8YZjvVe for ; Mon, 8 Oct 2012 21:45:32 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id E842E21F8491 for ; Mon, 8 Oct 2012 21:45:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1392; q=dns/txt; s=iport; t=1349757931; x=1350967531; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=z2cjRmB4ZsKdewjCD5MFRRXOAmrCQqvGaIwjwjXkeDo=; b=Ut104xxy+MY+ytyUs7PHCjyAeU523FzXaRFvnms+5XQDajaEvxbQXXW2 wB3ogs0C7Ak6AFy2U59iIYX9XN9P3fjuMKMVHQNatuZAGl7+TejwrPEbG 6+vum2756Y2HkS2SNdwAEcwsC452N5sIDRoFEJWeyfQXtZBz6Zl/eMAe6 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIWqc1CtJV2Y/2dsb2JhbABFvzSBCIIgAQEBBAEBAQ8BJzQLDAQCAQgRBAEBAQoUCQcnCxQJCAIEAQ0FCBqHYwuaXY9WkCMEgkOJBIUzYAOkMIFpgmANghc X-IronPort-AV: E=Sophos;i="4.80,557,1344211200"; d="scan'208";a="129600363" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP; 09 Oct 2012 04:45:30 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q994jUpp021076 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Oct 2012 04:45:30 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.220]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.001; Mon, 8 Oct 2012 23:45:29 -0500 From: "Gaurav Halwasia (ghalwasi)" To: Ted Lemon , "Bernie Volz (volz)" Thread-Topic: [dhcwg] DHCPv6 NoAddrAvailable Thread-Index: AQHNo0ybv/rzbuw1uEOtLX4rGo9ApJervjwAgAAjdwCAAPQJAIAAMFEAgAMHzQCAAAiwgIAAZZUAgAABhoCAAAzBAP//385A Date: Tue, 9 Oct 2012 04:45:29 +0000 Message-ID: <90903C21C73202418A48BFBE80AEE5EB1BD69783@xmb-aln-x06.cisco.com> References: <20121006002120.GA22039@shell-too.nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F5271DD@xmb-rcd-x04.cisco.com> <3DA1744868D7494E82766FBA8C916EAE@pheynix.net> <489D13FBFA9B3E41812EA89F188F018E0F52D9CB@xmb-rcd-x04.cisco.com> <20121008181120.GA29839@shell-too.nominum.com> <3BB803F8-F05F-47AA-9708-44E4A1A9C05D@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F5375CD@xmb-rcd-x04.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.142.106.26] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19252.004 x-tm-as-result: No--40.844000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] DHCPv6 NoAddrAvailable 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, 09 Oct 2012 04:45:36 -0000 What about if we say:- 1.) Server MUST put the status-code within IA_* if both NA and PD are reque= sted in same DHCPv6 message. =20 2.) Server can put status-code within IA_NA if only IA_NA is requested DHCP= v6 Message. (This will take care of backward compatibility) (behave as per = rfc 3315) Thanks, Gaurav -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= ed Lemon Sent: Tuesday, October 09, 2012 7:07 AM To: Bernie Volz (volz) Cc: dhcwg@ietf.org Subject: Re: [dhcwg] DHCPv6 NoAddrAvailable On Oct 8, 2012, at 8:51 PM, "Bernie Volz (volz)" wrote: > I'm much more in favor of documenting the existing behavior and living wi= th it (as I think that breaks fewer things). It isn't optimum, but in the e= nd it really doesn't matter as long as implementers understand what is expe= cted. And today that isn't as clear as it needs to be. >=20 > Perhaps the stateful issues draft can expand on this and clarify the serv= er's answer (using the example of what the returned message should look lik= e). That sounds right. It's not how we would have done it if we'd anticipated= prefix delegation when we did 3315, but that's water under the bridge. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From sunqi.thu@gmail.com Tue Oct 9 01:37:08 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E70F821F8844 for ; Tue, 9 Oct 2012 01:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.845 X-Spam-Level: X-Spam-Status: No, score=-1.845 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, 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 s-+raFMZbaU5 for ; Tue, 9 Oct 2012 01:37:08 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id F421F21F8847 for ; Tue, 9 Oct 2012 01:37:07 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id ro8so4987423pbb.31 for ; Tue, 09 Oct 2012 01:37:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:reply-to:subject:references:x-priority:x-guid:x-mailer :mime-version:message-id:content-type; bh=6YP0QEWqmRaVwSzbJFk7JkNtlRrFVaOB+yIXM7k1aFg=; b=CHgH98QbRVJ0TyygkRlql70u6phajx/iD75hK4RkPvJlQ7YQlJj9xXJ1Odf1N0cKPT v00Ku4JoHutHCMcOKSsVXlObfFyVhm0osDKJ6P3MpyOEkA5S5rANd1vRMkeIVTXm85pW l9iih9trdeJZlI2HTxbDHRWhyNkjUayXytSWpflYcHTajy/oGSGt36RA99mPtkNDRNnM JyWSovpKmESu+AU0Wt1BSnb3s/d0uwmiqJY1Alc9AVIGLMgG6wGX1YOHKF74qCj/u6kL GP7ZWG7WsvmXVDkBTwzv1BUfu37JwUp87kx5vmbCVyamg4tDjn0jYeuUEXACJygav6/9 YG9w== Received: by 10.68.218.226 with SMTP id pj2mr61974402pbc.33.1349771827707; Tue, 09 Oct 2012 01:37:07 -0700 (PDT) Received: from sunqi (tu131015.ip.tsinghua.edu.cn. [166.111.131.15]) by mx.google.com with ESMTPS id f2sm1143775paz.25.2012.10.09.01.37.03 (version=SSLv3 cipher=OTHER); Tue, 09 Oct 2012 01:37:06 -0700 (PDT) Date: Tue, 9 Oct 2012 16:36:58 +0800 From: "Qi Sun" To: "Ted Lemon" , "dhcwg@ietf.org" References: X-Priority: 3 X-GUID: C38AABC9-473E-4043-A186-31D5D460EC93 X-Mailer: Foxmail 7.0.1.83[cn] Mime-Version: 1.0 Message-ID: <201210091636588067901@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart884285343537_=----" Subject: Re: [dhcwg] Call for adoption: draft-mrugalski-softwire-dhcpv4-over-v6-option-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "sunqi.thu" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 08:37:09 -0000 This is a multi-part message in MIME format. ------=_001_NextPart884285343537_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RGVhciBUZWQsDQoNCkknbSBpbiBmYXZvciBvZiBhZG9wdGluZyB0aGlzIGRyYWZ0IGFzIGEgREhD IFdHIGl0ZW0uDQoNCkJlc3QgUmVnYXJkcyENCg0KDQoNCg0KUWkgU3VuDQoNCkZyb206IFRlZCBM ZW1vbg0KRGF0ZTogMjAxMi0wOS0yNyAwMToyNw0KVG86IGRoY3dnIFdHDQpTdWJqZWN0OiBbZGhj d2ddIENhbGwgZm9yIGFkb3B0aW9uOiBkcmFmdC1tcnVnYWxza2ktc29mdHdpcmUtZGhjcHY0LW92 ZXItdjYtb3B0aW9uLTAxDQpUaGUgYXV0aG9ycyBoYXZlIHJlcXVlc3RlZCB0aGF0IHRoZSB3b3Jr aW5nIGdyb3VwIGFkb3B0IGRyYWZ0LW1ydWdhbHNraS1zb2Z0d2lyZS1kaGNwdjQtb3Zlci12Ni1v cHRpb24gYXMgYSB3b3JraW5nIGdyb3VwIHdvcmsgaXRlbS4gICBUaGUgZG9jdW1lbnQgaXMgd2l0 aGluIHRoZSBzY29wZSBvZiB0aGUgY3VycmVudCBjaGFydGVyLiAgIEl0IGRlc2NyaWJlcyBhIERI Q1B2NiBvcHRpb24gdGhhdCBpcyB1c2VkIHRvIGNvbmZpZ3VyZSBjbGllbnQgcmVsYXkgYWdlbnRz IChkcmFmdC1pZXRmLWRoYy1kaGNwdjQtb3Zlci1pcHY2KS4NCg0KSWYgeW91IHRoaW5rIHRoZSB3 b3JraW5nIGdyb3VwIHNob3VsZCBiZSB3b3JraW5nIG9uIHN1Y2ggYW4gb3B0aW9uLCBwbGVhc2Ug cmVzcG9uZCB0byB0aGlzIG1lc3NhZ2UgYnkgc2F5aW5nIHNvLiAgIElmIHlvdSB0aGluayB3ZSBz aG91bGQgbm90LCBwbGVhc2Ugc2F5IHRoYXQuDQoNCldlIHdpbGwgZXZhbHVhdGUgY29uc2Vuc3Vz IG9uIG9yIGFmdGVyIE9jdG9iZXIgMTAuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpkaGN3ZyBtYWlsaW5nIGxpc3QNCmRoY3dnQGlldGYub3JnDQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RoY3dn ------=_001_NextPart884285343537_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Dear Ted,
 
I'm in favor of adopting this draft as a DHC WG item.
 
Best Regards!
 
Qi Sun
 
Date: 2012-09-27 01:27
Subject: [dhcwg] Call for adoption:=20 draft-mrugalski-softwire-dhcpv4-over-v6-option-01
The authors have requested that the wor= king group adopt draft-mrugalski-softwire-dhcpv4-over-v6-op= tion as a working group work item. &nbs= p; The document is within the scope of&= nbsp;the current charter.   It describes&nbs= p;a DHCPv6 option that is used to confi= gure client relay agents (draft-ietf-dhc-dhcpv4-over-i= pv6).
 
If you think the working group should&n= bsp;be working on such an option, please&nbs= p;respond to this message by saying so. = ;  If you think we should not, ple= ase say that.
 
We will evaluate consensus on or after&= nbsp;October 10.
 
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg
------=_001_NextPart884285343537_=------ From internet-drafts@ietf.org Tue Oct 9 23:47:40 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99BD321F8736; Tue, 9 Oct 2012 23:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.504 X-Spam-Level: X-Spam-Status: No, score=-102.504 tagged_above=-999 required=5 tests=[AWL=0.095, 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 dEvmY2KITKxp; Tue, 9 Oct 2012 23:47:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF0221F8715; Tue, 9 Oct 2012 23:47:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121010064740.31012.72995.idtracker@ietfa.amsl.com> Date: Tue, 09 Oct 2012 23:47:40 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-cga-config-dhcpv6-03.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 06:47:40 -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 Group = of the IETF. Title : Configuring Cryptographically Generated Addresses (CGA) = using DHCPv6 Author(s) : Sheng Jiang Sam(Zhongqi) Xia Filename : draft-ietf-dhc-cga-config-dhcpv6-03.txt Pages : 10 Date : 2012-10-09 Abstract: A Cryptographically Generated Address is an IPv6 addresses binding with a public/private key pair. However, the current CGA specifications are lack of procedures to enable proper management of the usage of CGAs. This document defines the process using DHCPv6 to manage CGAs in detail. A new DHCPv6 option is defined accordingly. This document also analyses the configuration of the parameters, which are used to generate CGAs, using DHCPv6. Although the document does not define new DHCPv6 option to carry these parameters for various reasons, the configuration procedure is described. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-cga-config-dhcpv6 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-cga-config-dhcpv6-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-cga-config-dhcpv6-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From otroan@employees.org Wed Oct 10 01:06:24 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30CCC21F8755 for ; Wed, 10 Oct 2012 01:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.092 X-Spam-Level: X-Spam-Status: No, score=-10.092 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 WW7hTckP8cCF for ; Wed, 10 Oct 2012 01:06:23 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 05A0421F874F for ; Wed, 10 Oct 2012 01:06:22 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAJsrdVCQ/khL/2dsb2JhbABEvyuBCIIgAQEBAwESAQodPwULC0ZXBi4Hh10Glw+gIJEGYAOkMIFrgm8 X-IronPort-AV: E=Sophos;i="4.80,564,1344211200"; d="scan'208";a="8673110" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-3.cisco.com with ESMTP; 10 Oct 2012 08:06:22 +0000 Received: from dhcp-lys01-vla250-10-147-112-212.cisco.com (dhcp-lys01-vla250-10-147-112-212.cisco.com [10.147.112.212]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9A86KPd019049 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 10 Oct 2012 08:06:21 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Wed, 10 Oct 2012 10:06:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2C2153F1-1FF3-4D30-8C7A-52B7AB7F21F0@employees.org> References: To: Ted Lemon X-Mailer: Apple Mail (2.1498) Cc: dhcwg WG Subject: Re: [dhcwg] Call for adoption: draft-mrugalski-softwire-dhcpv4-over-v6-option-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, 10 Oct 2012 08:06:24 -0000 > The authors have requested that the working group adopt = draft-mrugalski-softwire-dhcpv4-over-v6-option as a working group work = item. The document is within the scope of the current charter. It = describes a DHCPv6 option that is used to configure client relay agents = (draft-ietf-dhc-dhcpv4-over-ipv6). >=20 > If you think the working group should be working on such an option, = please respond to this message by saying so. If you think we should = not, please say that. I think we should not. including draft-ietf-dhc-dhcpv4-over-ipv6. a) DHC should wait until it is clear what the outcome of softwire is. = there are multiple solutions to the same problem proposed. hopefully one will not end up with standardizing all of them. DHCPv4 = over IPv6 is only needed in one of the solution sets. b) is this the right solution? if the working group doesn't think = solving the problem of running DHCPv6 over IPv4 should use a CRA. why is that the correct solution for DHCPv4 over IPv6? cheers, Ole= From Ted.Lemon@nominum.com Wed Oct 10 05:34:14 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C51621F86BE for ; Wed, 10 Oct 2012 05:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.329 X-Spam-Level: X-Spam-Status: No, score=-106.329 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 wjCuh4yzzpQB for ; Wed, 10 Oct 2012 05:34:13 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id AB69B21F8658 for ; Wed, 10 Oct 2012 05:34:13 -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 DSNKUHVrRGeVMpSaYFBf6N4fEMLvwl5VzORv@postini.com; Wed, 10 Oct 2012 05:34:13 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 A7FFD1B83A0 for ; Wed, 10 Oct 2012 05:34:11 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 7677619005C; Wed, 10 Oct 2012 05:34:11 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Wed, 10 Oct 2012 05:34:11 -0700 From: Ted Lemon To: =?iso-8859-1?Q?Ole_Tr=F8an?= Thread-Topic: [dhcwg] Call for adoption: draft-mrugalski-softwire-dhcpv4-over-v6-option-01 Thread-Index: AQHNnAwoksIIq5rbSkG4M+kw2Zj+pZeyuYEAgABK2IA= Date: Wed, 10 Oct 2012 12:34:10 +0000 Message-ID: References: <2C2153F1-1FF3-4D30-8C7A-52B7AB7F21F0@employees.org> In-Reply-To: <2C2153F1-1FF3-4D30-8C7A-52B7AB7F21F0@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dhcwg WG Subject: Re: [dhcwg] Call for adoption: draft-mrugalski-softwire-dhcpv4-over-v6-option-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, 10 Oct 2012 12:34:14 -0000 On Oct 10, 2012, at 4:06 AM, Ole Tr=F8an wrote: > a) DHC should wait until it is clear what the outcome of softwire is. the= re are multiple solutions to the same problem proposed. > hopefully one will not end up with standardizing all of them. DHCPv4 o= ver IPv6 is only needed in one of the solution sets. > b) is this the right solution? if the working group doesn't think solving= the problem of running DHCPv6 over IPv4 should use a CRA. > why is that the correct solution for DHCPv4 over IPv6? The working group has already adopted dhcpv4-over-ipv6. This is an option= to carry the IPv6 address of the DHCPv4-over-IPv6 server to the CRA so tha= t it can relay correctly.= From Ted.Lemon@nominum.com Wed Oct 10 06:30:59 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F98921F86D6 for ; Wed, 10 Oct 2012 06:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.478 X-Spam-Level: X-Spam-Status: No, score=-106.478 tagged_above=-999 required=5 tests=[AWL=0.121, 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 MLkZ3tfuAE6G for ; Wed, 10 Oct 2012 06:30:58 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id 6394D21F86C3 for ; Wed, 10 Oct 2012 06:30:58 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKUHV4kdW20N46z3mpeZL8Ipy1UMe42A0z@postini.com; Wed, 10 Oct 2012 06:30: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 737961B8380 for ; Wed, 10 Oct 2012 06:30:57 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 6967519005C for ; Wed, 10 Oct 2012 06:30:57 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Wed, 10 Oct 2012 06:30:57 -0700 From: Ted Lemon To: dhcwg WG Thread-Topic: Call for adoption: draft-sun-dhc-port-set-option Thread-Index: AQHNput68Hhly3n5akOtNZsf4t9jOg== Date: Wed, 10 Oct 2012 13:30:57 +0000 Message-ID: <9D3C0AC1-D5B1-4C25-AC47-4D08E3252D54@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <5F43E0B908950449B3DBE9A295600660@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dhcwg] Call for adoption: draft-sun-dhc-port-set-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, 10 Oct 2012 13:30:59 -0000 The authors of this draft have asked the DHC working group to adopt it as a= work item. This document describes a new DHCPv4 option which allows the DHCPv4 server = to assign a set of ports to a user device during the IPv4 address provision= ing process. By assigning the same IPv4 address with non-overlaped port se= ts to multiple clients, the clients can share the IPv4 address and continue= to deliver IPv4 services to subscribers. Remember, the document just describes the DHCP option, not the whole lightw= eight 4over6 work. If you support working on a draft documenting such an = option, and are willing to start from this work, please say so on the maili= ng list. If you think the working group shouldn't do this work, or that t= his draft is the wrong place to start, please say so on the mailing list. We will evaluate working group consensus for adoption on October 24.= From Tina.Tsou.Zouting@huawei.com Wed Oct 10 10:11:30 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D38D21F8724 for ; Wed, 10 Oct 2012 10:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.461 X-Spam-Level: X-Spam-Status: No, score=-6.461 tagged_above=-999 required=5 tests=[AWL=0.138, 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 c13bZ7Qj67y7 for ; Wed, 10 Oct 2012 10:11:29 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9703321F871C for ; Wed, 10 Oct 2012 10:11:28 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKM26346; Wed, 10 Oct 2012 17:11:27 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 10 Oct 2012 18:10:36 +0100 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 10 Oct 2012 18:10:52 +0100 Received: from DFWEML513-MBS.china.huawei.com ([169.254.4.43]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.003; Wed, 10 Oct 2012 10:10:46 -0700 From: Tina TSOU To: Ted Lemon Thread-Topic: [dhcwg] Call for adoption: draft-sun-dhc-port-set-option Thread-Index: AQHNpwovinN7gKt5S0i1E4DpU8IFHA== Date: Wed, 10 Oct 2012 17:10:45 +0000 Message-ID: References: <9D3C0AC1-D5B1-4C25-AC47-4D08E3252D54@nominum.com> In-Reply-To: <9D3C0AC1-D5B1-4C25-AC47-4D08E3252D54@nominum.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: dhcwg WG Subject: Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-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, 10 Oct 2012 17:11:30 -0000 Support. Tina On Oct 10, 2012, at 6:31 AM, "Ted Lemon" wrote: > The authors of this draft have asked the DHC working group to adopt it as= a work item. >=20 > This document describes a new DHCPv4 option which allows the DHCPv4 serve= r to assign a set of ports to a user device during the IPv4 address provisi= oning process. By assigning the same IPv4 address with non-overlaped port = sets to multiple clients, the clients can share the IPv4 address and contin= ue to deliver IPv4 services to subscribers. >=20 > Remember, the document just describes the DHCP option, not the whole ligh= tweight 4over6 work. If you support working on a draft documenting such a= n option, and are willing to start from this work, please say so on the mai= ling list. If you think the working group shouldn't do this work, or that= this draft is the wrong place to start, please say so on the mailing list. >=20 > We will evaluate working group consensus for adoption on October 24. > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From sunqi.thu@gmail.com Thu Oct 11 00:34:48 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE02A21F8710 for ; Thu, 11 Oct 2012 00:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.545 X-Spam-Level: X-Spam-Status: No, score=-1.545 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, 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 q81FigjV7VlH for ; Thu, 11 Oct 2012 00:34:48 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 59D1221F86F0 for ; Thu, 11 Oct 2012 00:34:48 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id ro8so1581253pbb.31 for ; Thu, 11 Oct 2012 00:34:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:reply-to:subject:references:x-priority:x-guid :x-mailer:mime-version:message-id:content-type; bh=SBytza7S2d798318D04MWV4JTbz8ZDhRp9m2j3LF5O0=; b=YK2kEW51NTeXn6ffBTJYuaOnqOyv9GwrgV7e8ufU27DeHtGvGwVR/RFN886Kzwm6np quNFqG9YogVbbOZgP1l/XwQiVbe3j1AmayjMIzaEM6iAvnBm8Z3Xb+IOwGbnrz793GXu 32oAPUEbTGTsVMQQIoIPu9Fl+92UUqZdv1J5txjiR9JKQMYr9JqOT1Uf/CwPy84FdRJr BV0yMSdmyj9BVoI6vz+n5bAMA8AcLamjv6KDX8ioG/Qv3av7QVd10Rn62Hfmb+9+DetV T/CJ7UOO2H8G7U9whMXUyKCymE4+hRMM+1AR+WVr0udg6gkgC6j103Pxb1hJW3lldpL6 4cxA== Received: by 10.68.221.168 with SMTP id qf8mr1248440pbc.37.1349940888081; Thu, 11 Oct 2012 00:34:48 -0700 (PDT) Received: from sunqi ([114.255.41.137]) by mx.google.com with ESMTPS id no1sm708560pbc.21.2012.10.11.00.34.44 (version=SSLv3 cipher=OTHER); Thu, 11 Oct 2012 00:34:47 -0700 (PDT) Date: Thu, 11 Oct 2012 15:34:40 +0800 From: "Qi Sun" To: =?gb2312?B?T2xlIFRy+GFu?= , "Ted Lemon" References: , <2C2153F1-1FF3-4D30-8C7A-52B7AB7F21F0@employees.org> X-Priority: 3 X-GUID: 81E62F1C-6DDC-42AD-9A64-766C753F8C89 X-Mailer: Foxmail 7.0.1.83[cn] Mime-Version: 1.0 Message-ID: <2012101111311241723818@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart882156110178_=----" Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Call for adoption: draft-mrugalski-softwire-dhcpv4-over-v6-option-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "sunqi.thu" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 07:34:49 -0000 This is a multi-part message in MIME format. ------=_001_NextPart882156110178_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgT2xlLA0KDQpQbGVhc2Ugc2VlIG15IG9waW5pb25zIGlubGluZS4NCg0KDQoNCg0KUWkgU3Vu DQoNCkZyb206IE9sZSBUcvhhbg0KRGF0ZTogMjAxMi0xMC0xMCAxNjowNg0KVG86IFRlZCBMZW1v bg0KQ0M6IGRoY3dnIFdHDQpTdWJqZWN0OiBSZTogW2RoY3dnXSBDYWxsIGZvciBhZG9wdGlvbjog ZHJhZnQtbXJ1Z2Fsc2tpLXNvZnR3aXJlLWRoY3B2NC1vdmVyLXY2LW9wdGlvbi0wMQ0KPiBUaGUg YXV0aG9ycyBoYXZlIHJlcXVlc3RlZCB0aGF0IHRoZSB3b3JraW5nIGdyb3VwIGFkb3B0IGRyYWZ0 LW1ydWdhbHNraS1zb2Z0d2lyZS1kaGNwdjQtb3Zlci12Ni1vcHRpb24gYXMgYSB3b3JraW5nIGdy b3VwIHdvcmsgaXRlbS4gICBUaGUgZG9jdW1lbnQgaXMgd2l0aGluIHRoZSBzY29wZSBvZiB0aGUg Y3VycmVudCBjaGFydGVyLiAgIEl0IGRlc2NyaWJlcyBhIERIQ1B2NiBvcHRpb24gdGhhdCBpcyB1 c2VkIHRvIGNvbmZpZ3VyZSBjbGllbnQgcmVsYXkgYWdlbnRzIChkcmFmdC1pZXRmLWRoYy1kaGNw djQtb3Zlci1pcHY2KS4NCj4gDQo+IElmIHlvdSB0aGluayB0aGUgd29ya2luZyBncm91cCBzaG91 bGQgYmUgd29ya2luZyBvbiBzdWNoIGFuIG9wdGlvbiwgcGxlYXNlIHJlc3BvbmQgdG8gdGhpcyBt ZXNzYWdlIGJ5IHNheWluZyBzby4gICBJZiB5b3UgdGhpbmsgd2Ugc2hvdWxkIG5vdCwgcGxlYXNl IHNheSB0aGF0Lg0KDQpJIHRoaW5rIHdlIHNob3VsZCBub3QuIGluY2x1ZGluZyBkcmFmdC1pZXRm LWRoYy1kaGNwdjQtb3Zlci1pcHY2Lg0KDQoNCmEpIERIQyBzaG91bGQgd2FpdCB1bnRpbCBpdCBp cyBjbGVhciB3aGF0IHRoZSBvdXRjb21lIG9mIHNvZnR3aXJlIGlzLiB0aGVyZSBhcmUgbXVsdGlw bGUgc29sdXRpb25zIHRvIHRoZSBzYW1lIHByb2JsZW0gcHJvcG9zZWQuDQogICAgaG9wZWZ1bGx5 IG9uZSB3aWxsIG5vdCBlbmQgdXAgd2l0aCBzdGFuZGFyZGl6aW5nIGFsbCBvZiB0aGVtLiBESENQ djQgb3ZlciBJUHY2IGlzIG9ubHkgbmVlZGVkIGluIG9uZSBvZiB0aGUgc29sdXRpb24gc2V0cy4N CmIpIGlzIHRoaXMgdGhlIHJpZ2h0IHNvbHV0aW9uPyBpZiB0aGUgd29ya2luZyBncm91cCBkb2Vz bid0IHRoaW5rIHNvbHZpbmcgdGhlIHByb2JsZW0gb2YgcnVubmluZyBESENQdjYgb3ZlciBJUHY0 IHNob3VsZCB1c2UgYSBDUkEuDQogICAgd2h5IGlzIHRoYXQgdGhlIGNvcnJlY3Qgc29sdXRpb24g Zm9yIERIQ1B2NCBvdmVyIElQdjY/DQoNCltRaV0gMSkgSW4gSVB2NC1vdmVyLUlQdjYgc2NlbmFy aW9zLCBpdCBpcyBuZWVkZWQgdG8gYWxsb2NhdGUgSVB2NCBhZGRyZXNzIHRvIHVzZXJzIGluIElQ djYgYWNjZXNzIG5ldHdvcmsuIERIQ1B2NCBpcyB0aGUgcmlnaHQgcHJvdG9jb2wgdG8gYXNzaWdu IElQdjQgYWRkcmVzcy4gDQogICAgICAgMikgVXNpbmcgYSBDbGllbnQgUmVsYXkgQWdlbnQgaXMg aGVscGZ1bCB0byBhdm9pZCBtb2RpZmljYXRpb25zIG9mIERIQ1B2NCBjbGllbnQsIHdoaWNoIHdp bGwgY2F1c2UgbGVzcyBjaGFuZ2UgdG8gY3VycmVudCBuZXR3b3JrIGFuZCB1c2Vycy4NCiAgICAg ICAzKSBkcmFmdC1tcnVnYWxza2ktc29mdHdpcmUtZGhjcHY0LW92ZXItdjYtb3B0aW9uIGRlc2Ny aWJlcyBhIERIQ1B2NiBvcHRpb24gdGhhdCBpcyB1c2VkIHRvIHRlbGwgdGhlIENSQSB0aGUgdW5p Y2FzdCBJUHY2IGFkZHJlc3Mgb2YgVFNWL1RSQS4gSU1PIHRoaXMgb3B0aW9uIGNhbiBtYWtlIHRo ZSBDUkEgd29yayBiZXR0ZXIuDQoNCkJlc3QgUmVnYXJkcyENClFpIFN1bg0KDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpkaGN3ZyBtYWlsaW5nIGxp c3QNCmRoY3dnQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2RoY3dn ------=_001_NextPart882156110178_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hi Ole,
 
Please see my opinions inline.
 
Qi Sun
 
Date: 2012-10-10 16:06
Subject: Re: [dhcwg] Call for adoption:=20 draft-mrugalski-softwire-dhcpv4-over-v6-option-01
> The authors have requested that th= e working group adopt draft-mrugalski-softwire-dhcpv4-= over-v6-option as a working group work item.=    The document is within the scop= e of the current charter.   It des= cribes a DHCPv6 option that is used to&= nbsp;configure client relay agents (draft-ietf-dhc-dhc= pv4-over-ipv6).
> 
> If you think the working group&nbs= p;should be working on such an option, = please respond to this message by saying&nbs= p;so.   If you think we should not= , please say that.
 
I think we should not. including draft-= ietf-dhc-dhcpv4-over-ipv6.
 
 
a) DHC should wait until it is cle= ar what the outcome of softwire is. the= re are multiple solutions to the same p= roblem proposed.
    hopefully one will not en= d up with standardizing all of them. DH= CPv4 over IPv6 is only needed in one&nb= sp;of the solution sets.
b) is this the right solution? if = the working group doesn't think solving the&= nbsp;problem of running DHCPv6 over IPv4 sho= uld use a CRA.
    why is that the correct&n= bsp;solution for DHCPv4 over IPv6?
 
[Qi] 1) In IPv4-over-IPv6 scenarios, it is needed to allocate IPv4 ad= dress=20 to users in IPv6 access network. DHCPv4 is the right protocol to assign IP= v4=20 address.
       2) Using a Client Relay Agent is= =20 helpful to avoid modifications of DHCPv4 client, which will cause les= s=20 change to current network and users.
       3)=20 draft-mrugalski-softwire-dhcpv4-over-v6-option describes a=20 DHCPv6 option that is used to tell the CRA the unicast IPv6 addr= ess of=20 TSV/TRA. IMO this option can make the CRA work better.
 
Best Regards!
Qi Sun
 
 
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg
------=_001_NextPart882156110178_=------ From pengwu.thu@gmail.com Thu Oct 11 01:10:30 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80D4C21F86EF for ; Thu, 11 Oct 2012 01:10:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 xqf3hqWoFnS6 for ; Thu, 11 Oct 2012 01:10:30 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id C0EA621F86E2 for ; Thu, 11 Oct 2012 01:10:29 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so1628435vbb.31 for ; Thu, 11 Oct 2012 01:10:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=X8AtIpRFPQe6ZBUeIlaaExPCMxIb1hFi8aZOGJSepXg=; b=W5ZLt1BAH5Bi37BNzxBJkTCxQo91RKWgJIUOiQxLr7B0/ED3Fn35Djq0qE9YnyyLZa 2pR0CmoCcyjMwJ6jX3WxXulKhqT0BX10NKiDaTYrTfSxMXt7YY0V4RM10f0Lfz+iiAJl lk5EMHeD14Mgo/mZcDWX1xeQHWrN0xsypc0NIHQVjZiYsqjTAjfR1+6W3xXyWqMf/YHk NANoGwmf9SIVVq1YNdFHDczgFT3U0yYXnTiP0LVKsVW6zYS40dLUJr3MeHbQym5owSng 6Q2DMZsO53xcqSqxiPHcJ9D4nThvlUOebYqPAqkKym5sB4zAfE2+EdiFYm3pZApkAS2p B2zw== MIME-Version: 1.0 Received: by 10.52.89.172 with SMTP id bp12mr49459vdb.19.1349943028938; Thu, 11 Oct 2012 01:10:28 -0700 (PDT) Received: by 10.58.163.102 with HTTP; Thu, 11 Oct 2012 01:10:28 -0700 (PDT) In-Reply-To: <9D3C0AC1-D5B1-4C25-AC47-4D08E3252D54@nominum.com> References: <9D3C0AC1-D5B1-4C25-AC47-4D08E3252D54@nominum.com> Date: Thu, 11 Oct 2012 16:10:28 +0800 Message-ID: From: Peng Wu To: Ted Lemon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dhcwg WG Subject: Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-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, 11 Oct 2012 08:10:30 -0000 I support to adopt this document. We've been on this topic for quite a long period. I'm happy to hear that we finally makes technical progress and produces this latest draft which describes the problem and the approach clearly. we can make technical progress and produce this new, latest draft. On Wed, Oct 10, 2012 at 9:30 PM, Ted Lemon wrote: > The authors of this draft have asked the DHC working group to adopt it as= a work item. > > This document describes a new DHCPv4 option which allows the DHCPv4 serve= r to assign a set of ports to a user device during the IPv4 address provisi= oning process. By assigning the same IPv4 address with non-overlaped port = sets to multiple clients, the clients can share the IPv4 address and contin= ue to deliver IPv4 services to subscribers. > > Remember, the document just describes the DHCP option, not the whole ligh= tweight 4over6 work. If you support working on a draft documenting such a= n option, and are willing to start from this work, please say so on the mai= ling list. If you think the working group shouldn't do this work, or that= this draft is the wrong place to start, please say so on the mailing list. > > We will evaluate working group consensus for adoption on October 24. > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From sunqi.thu@gmail.com Thu Oct 11 05:55:09 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9F5111E809A for ; Thu, 11 Oct 2012 05:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[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 Bse3cKtedzjm for ; Thu, 11 Oct 2012 05:55:09 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id F405D21F8714 for ; Thu, 11 Oct 2012 05:55:07 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id s14so1515892qcg.31 for ; Thu, 11 Oct 2012 05:55:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=cXLNdMlRbEUQXkkMTkbnyRyF6MoZTciDDQ8rt8IglBs=; b=lPZHofQhAaChKLA01aF4dqO51WG9PwkBYx3TuXdSgbNvBuC6tP5MN9qN8Pt9ymVwA6 c/8YrVEJdh4eqe5Efvn2dRnfVF2p0LEK80I6qlI5qvjrGBre7/kpeI2v1g1nqEJ1FLML ysH1VLLKuyuKKLNCzo/IpPlvyv9NCN2tCPJxwtVku1D8stGkE9WuinKUZJjGLXX94Kum ZOtOPKrUWDWQMuqe8WZ54uytxqht4cr94Cm5uWSTouMfILVJ7dwyR+hDcil8BjAUACGb 2+kpQnlPTJWrgE+m4gC0f4g3EuqEt2Kl+/1Q5+XMbPOmQPdaNC9jD+GojyMps4GN0ils 6IkA== MIME-Version: 1.0 Received: by 10.224.189.12 with SMTP id dc12mr1535501qab.59.1349960107211; Thu, 11 Oct 2012 05:55:07 -0700 (PDT) Received: by 10.49.50.105 with HTTP; Thu, 11 Oct 2012 05:55:07 -0700 (PDT) In-Reply-To: References: Date: Thu, 11 Oct 2012 20:55:07 +0800 Message-ID: From: Sun Qi To: Ted Lemon , "dhcwg@ietf.org" Content-Type: multipart/alternative; boundary=485b397dd5b3a6bb9e04cbc81471 Subject: Re: [dhcwg] Call for adoption: draft-mrugalski-softwire-dhcpv4-over-v6-option-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, 11 Oct 2012 12:55:09 -0000 --485b397dd5b3a6bb9e04cbc81471 Content-Type: text/plain; charset=ISO-8859-1 ** Dear Ted, I'm in favor of adopting this draft as a DHC WG item. Best Regards! ------------------------------ Qi Sun *From:* Ted Lemon *Date:* 2012-09-27 01:27 *To:* dhcwg WG *Subject:* [dhcwg] Call for adoption: draft-mrugalski-softwire-dhcpv4-over-v6-option-01 The authors have requested that the working group adopt draft-mrugalski-softwire-dhcpv4-over-v6-option as a working group work item. The document is within the scope of the current charter. It describes a DHCPv6 option that is used to configure client relay agents (draft-ietf-dhc-dhcpv4-over-ipv6). If you think the working group should be working on such an option, please respond to this message by saying so. If you think we should not, please say that. We will evaluate consensus on or after October 10. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg --485b397dd5b3a6bb9e04cbc81471 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear Ted,
=A0
I'm in favor of adopting this draft as a=A0DHC WG item.
=A0
Best Regards!
=A0
Qi Sun
=A0
From:=A0Ted Lemon
Date:=A02012-09-27=A001:27
To:=A0dhcwg= WG
Subject:=A0[dhcwg] Call for adoption: draft-mrugalski-softwire-= dhcpv4-over-v6-option-01
The=A0authors=A0have=A0requested=A0that=A0the=A0working=A0group=A0adop= t=A0draft-mrugalski-softwire-dhcpv4-over-v6-option=A0as=A0a=A0working=A0gro= up=A0work=A0item.=A0=A0=A0The=A0document=A0is=A0within=A0the=A0scope=A0of= =A0the=A0current=A0charter.=A0=A0=A0It=A0describes=A0a=A0DHCPv6=A0option=A0= that=A0is=A0used=A0to=A0configure=A0client=A0relay=A0agents=A0(draft-ietf-d= hc-dhcpv4-over-ipv6).
=A0
If=A0you=A0think=A0the=A0working=A0group=A0should=A0be=A0working=A0on= =A0such=A0an=A0option,=A0please=A0respond=A0to=A0this=A0message=A0by=A0sayi= ng=A0so.=A0=A0=A0If=A0you=A0think=A0we=A0should=A0not,=A0please=A0say=A0tha= t.
=A0
We=A0will=A0evaluate=A0consensus=A0on=A0or=A0after=A0October=A010.
=A0
_______________________________________________
dhcwg=A0mailing=A0list
--485b397dd5b3a6bb9e04cbc81471-- From sunqi.thu@gmail.com Thu Oct 11 05:57:50 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B51D821F8779 for ; Thu, 11 Oct 2012 05:57:50 -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, MIME_8BIT_HEADER=0.3, 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 hHUPCxUSuxK4 for ; Thu, 11 Oct 2012 05:57:50 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id F3B2221F8740 for ; Thu, 11 Oct 2012 05:57:49 -0700 (PDT) Received: by mail-qa0-f51.google.com with SMTP id j40so1401026qab.10 for ; Thu, 11 Oct 2012 05:57:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=upOEHRrbD0t3Aamk9Ln84nb4kMqUauW4xI4rzRVD6lw=; b=g820BYSQ4WZjDLdKdBfDiPkP0ymEQDndHW6yQClDEPIxRz7tgZq37Gxr17rip702B6 ZpmfJFiUdbZGdQ32PXGWKpFKjOXlWwHw+pBy/+szFDzD3GOR3Ojmybqh7syYiW+GphKM 8r7SNMCeAVFMYbXSPSYVabrM5hnx8m9Ekop4ma+nOAfcwGl9WQmTpxVCZs6dk5LtUioJ ebsSCNuHwhfRGKWPvb4ekrnd5i/ODI7EY9uj8orRjiW/71lFcRN/FF6Ls7pcUD1y9blb KU8ulnK6AVjSRIo8D0mrRJMk75I5uO4Y2QK1v3MI92KnnYSZDCtRs1MJz4jQyjkGfSlx ocQQ== MIME-Version: 1.0 Received: by 10.229.206.37 with SMTP id fs37mr316720qcb.65.1349960269408; Thu, 11 Oct 2012 05:57:49 -0700 (PDT) Received: by 10.49.50.105 with HTTP; Thu, 11 Oct 2012 05:57:49 -0700 (PDT) In-Reply-To: <2C2153F1-1FF3-4D30-8C7A-52B7AB7F21F0@employees.org> References: <2C2153F1-1FF3-4D30-8C7A-52B7AB7F21F0@employees.org> Date: Thu, 11 Oct 2012 20:57:49 +0800 Message-ID: From: Sun Qi To: =?ISO-8859-1?Q?Ole_Tr=F8an?= Content-Type: multipart/alternative; boundary=0016369f9c7b51a9f904cbc81e91 Cc: dhcwg WG , Ted Lemon Subject: Re: [dhcwg] Call for adoption: draft-mrugalski-softwire-dhcpv4-over-v6-option-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, 11 Oct 2012 12:57:50 -0000 --0016369f9c7b51a9f904cbc81e91 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Ole, Here are my opinions. 1) In IPv4-over-IPv6 scenarios, it is needed to allocate IPv4 address to users in IPv6 access network. DHCPv4 is the right protocol to assign IPv4 address. 2) Using a Client Relay Agent is helpful to avoid modifications of DHCPv4 client, which will cause less change to current network and users. 3) draft-mrugalski-softwire-dhcpv4-over-v6-option describes a DHCPv6 option that is used to tell the CRA the unicast IPv6 address of TSV/TRA. IMO this option can make the CRA work better. Best Regards! Qi Sun 2012/10/10 Ole Tr=F8an > > The authors have requested that the working group adopt > draft-mrugalski-softwire-dhcpv4-over-v6-option as a working group work > item. The document is within the scope of the current charter. It > describes a DHCPv6 option that is used to configure client relay agents > (draft-ietf-dhc-dhcpv4-over-ipv6). > > > > If you think the working group should be working on such an option, > please respond to this message by saying so. If you think we should not= , > please say that. > > I think we should not. including draft-ietf-dhc-dhcpv4-over-ipv6. > > a) DHC should wait until it is clear what the outcome of softwire is. > there are multiple solutions to the same problem proposed. > hopefully one will not end up with standardizing all of them. DHCPv4 > over IPv6 is only needed in one of the solution sets. > b) is this the right solution? if the working group doesn't think solving > the problem of running DHCPv6 over IPv4 should use a CRA. > why is that the correct solution for DHCPv4 over IPv6? > > cheers, > Ole > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > --0016369f9c7b51a9f904cbc81e91 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Ole,
=A0
Here are my opinions.
=A0
1) In IPv4-over-IPv6 scenarios, it is needed to allocate IPv4 address = to users in IPv6 access network. DHCPv4 is the right protocol to assign IPv= 4 address.=A0

2) Using a Client Relay Agent is helpful to avoid modifications of= DHCPv4 client, which will cause less change to current network and users.<= /div>

3) draft-mrugalski-softwire-dhcpv4-over-v6-option describes a DHCP= v6 option that is used to tell the CRA the unicast IPv6 address of TSV/TRA.= IMO this option can make the CRA work better.
=A0
Best Regards!
Qi Sun

2012/10/10 Ole Tr=F8an <otroan@employees.org= >
> The authors have requested that the working group ad= opt draft-mrugalski-softwire-dhcpv4-over-v6-option as a working group work = item. =A0 The document is within the scope of the current charter. =A0 It d= escribes a DHCPv6 option that is used to configure client relay agents (dra= ft-ietf-dhc-dhcpv4-over-ipv6).
>
> If you think the working group should be working on such an op= tion, please respond to this message by saying so. =A0 If you think we shou= ld not, please say that.

I think we should not. including draf= t-ietf-dhc-dhcpv4-over-ipv6.

a) DHC should wait until it is clear what the outcome of softwire is. t= here are multiple solutions to the same problem proposed.
=A0 =A0 hopefu= lly one will not end up with standardizing all of them. DHCPv4 over IPv6 is= only needed in one of the solution sets.
b) is this the right solution? if the working group doesn't think solvi= ng the problem of running DHCPv6 over IPv4 should use a CRA.
=A0 =A0 why= is that the correct solution for DHCPv4 over IPv6?

cheers,
Ole
_______________________________________________
dhcwg = mailing list
dhcwg@ietf.org
http= s://www.ietf.org/mailman/listinfo/dhcwg

--0016369f9c7b51a9f904cbc81e91-- From internet-drafts@ietf.org Sun Oct 14 18:25:55 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 928B121F8460; Sun, 14 Oct 2012 18:25:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 S+M+Ad8e5cJL; Sun, 14 Oct 2012 18:25:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C4E321F8469; Sun, 14 Oct 2012 18:25:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121015012555.13059.51170.idtracker@ietfa.amsl.com> Date: Sun, 14 Oct 2012 18:25:55 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-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, 15 Oct 2012 01:25:55 -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 Group = of the IETF. Title : RADIUS Option for DHCPv6 Relay Agents on Broadband Acces= s Server Author(s) : Leaf Y. Yeh Mohamed Boucadair Ted Lemon Filename : draft-ietf-dhc-dhcpv6-radius-opt-02.txt Pages : 9 Date : 2012-10-14 Abstract: The DHCPv6 RADIUS option provides a mechanism to exchange authorization and identification information between relay agent and server. This mechanism is meant to the centralized DHCPv6 server to select the right configuration for the requesting client based on the authorization information received from the RADIUS server, which is not co-located with the DHCPv6 server. NAS acts as DHCPv6 relay agent and RADIUS client simultaneously in this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-radius-opt There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-radius-opt-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-dhcpv6-radius-opt-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From leaf.y.yeh@huawei.com Sun Oct 14 18:37:42 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DBC221F852A for ; Sun, 14 Oct 2012 18:37:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.477 X-Spam-Level: X-Spam-Status: No, score=-6.477 tagged_above=-999 required=5 tests=[AWL=0.122, 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 SW80ihPXMU+2 for ; Sun, 14 Oct 2012 18:37:41 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 48CBA21F853C for ; Sun, 14 Oct 2012 18:37:41 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKP23632; Mon, 15 Oct 2012 01:37:40 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 15 Oct 2012 02:37:11 +0100 Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 15 Oct 2012 02:37:39 +0100 Received: from SZXEML546-MBX.china.huawei.com ([169.254.3.192]) by szxeml403-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Mon, 15 Oct 2012 09:37:36 +0800 From: Leaf yeh To: "dhcwg@ietf.org" Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-02.txt Thread-Index: AQHNqnQfbEoJIh9AJE+Vxhw5BcdyMpe5lIBQ Date: Mon, 15 Oct 2012 01:37:35 +0000 Message-ID: References: <20121015012555.13059.51170.idtracker@ietfa.amsl.com> In-Reply-To: <20121015012555.13059.51170.idtracker@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.83.152] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-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, 15 Oct 2012 01:37:42 -0000 Draft (OPTION_RADIUS) has been updated to ver.-02.=20 The updates can be found at http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-d= hc-dhcpv6-radius-opt-02 . The meaningful revisions from ver.-01 are: a. removed the attribute of Frame-Pool (88) from the table in section 4, ca= use it is supposed to belong to IPv4;=20 b. added RFC6519 as a reference in section 1,=20 c. added some text about renew/rebind in section 3; Best Regards, Leaf -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of i= nternet-drafts@ietf.org Sent: Monday, October 15, 2012 9:26 AM To: i-d-announce@ietf.org Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-02.txt 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 Group = of the IETF. Title : RADIUS Option for DHCPv6 Relay Agents on Broadband Acces= s Server Author(s) : Leaf Y. Yeh Mohamed Boucadair Ted Lemon Filename : draft-ietf-dhc-dhcpv6-radius-opt-02.txt Pages : 9 Date : 2012-10-14 Abstract: The DHCPv6 RADIUS option provides a mechanism to exchange authorization and identification information between relay agent and server. This mechanism is meant to the centralized DHCPv6 server to select the right configuration for the requesting client based on the authorization information received from the RADIUS server, which is not co-located with the DHCPv6 server. NAS acts as DHCPv6 relay agent and RADIUS client simultaneously in this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-radius-opt There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-radius-opt-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-dhcpv6-radius-opt-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From internet-drafts@ietf.org Mon Oct 15 13:43:17 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E358E21F8A4A; Mon, 15 Oct 2012 13:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.037, 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 AZvKVakaYjXZ; Mon, 15 Oct 2012 13:43:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 360D621F8A3C; Mon, 15 Oct 2012 13:43: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: 4.34 Message-ID: <20121015204317.24531.96812.idtracker@ietfa.amsl.com> Date: Mon, 15 Oct 2012 13:43:17 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv4-bulk-leasequery-07.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, 15 Oct 2012 20:43:18 -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 Group = of the IETF. Title : Bulk DHCPv4 Lease Query Author(s) : Kim Kinnear Mark Stapp Bharat Joshi Neil Russell Filename : draft-ietf-dhc-dhcpv4-bulk-leasequery-07.txt Pages : 40 Date : 2012-10-15 Abstract: 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv4-bulk-leasequery There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-dhcpv4-bulk-leasequery-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-dhcpv4-bulk-leasequery-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ian.farrer@telekom.de Mon Oct 15 21:36:23 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA7D321F87A2 for ; Mon, 15 Oct 2012 21:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 5G8kQxjA6s-m for ; Mon, 15 Oct 2012 21:36:21 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by ietfa.amsl.com (Postfix) with ESMTP id 35BE621F87A1 for ; Mon, 15 Oct 2012 21:36:20 -0700 (PDT) Received: from he113657.emea1.cds.t-internal.com ([10.134.99.17]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 16 Oct 2012 06:36:19 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113657.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 16 Oct 2012 06:36:18 +0200 From: To: Date: Tue, 16 Oct 2012 06:36:17 +0200 Thread-Topic: RE: [dhcwg] Call for adoption: draft-sun-dhc-port-set-option Thread-Index: Ac2rV8hmg7L9Z5z0T/+B6okBSRIHVQ== Message-ID: <8A1B81989BCFAE44A22B2B86BF2B7631893D13867E@HE111643.EMEA1.CDS.T-INTERNAL.COM> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: multipart/alternative; boundary="_000_8A1B81989BCFAE44A22B2B86BF2B7631893D13867EHE111643EMEA1_" MIME-Version: 1.0 Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-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, 16 Oct 2012 04:36:23 -0000 --_000_8A1B81989BCFAE44A22B2B86BF2B7631893D13867EHE111643EMEA1_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I support the adoption of this draft. BR, Ian On Oct 10, 2012, at 6:31 AM, "Ted Lemon" wrote: >The authors of this draft have asked the DHC working group to adopt it as = a work item. > >This document describes a new DHCPv4 option which allows the DHCPv4 server= to assign a set of ports to a user device during the IPv4 address provisio= ning process. By assigning the same IPv4 address with non-overlaped port s= ets to multiple clients, the clients can share the IPv4 address and continu= e to deliver IPv4 services to subscribers. > >Remember, the document just describes the DHCP option, not the whole light= weight 4over6 work. If you support working on a draft documenting such an= option, and are willing to start from this work, please say so on the mail= ing list. If you think the working group shouldn't do this work, or that = this draft is the wrong place to start, please say so on the mailing list. > >We will evaluate working group consensus for adoption on October 24. >_______________________________________________ > dhcwg mailing list > dhcwg at ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg --_000_8A1B81989BCFAE44A22B2B86BF2B7631893D13867EHE111643EMEA1_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I support the adoption= of this draft.
BR,
Ian
 
On Oct 10, 2012, at 6:= 31 AM, "Ted Lemon" <Ted.Lemon at nominum.com> wrote:
>The authors of t= his draft have asked the DHC working group to adopt it as a work item.
>
>This document de= scribes a new DHCPv4 option which allows the DHCPv4 server to assign a set = of ports to a user device during the IPv4 address provisioning process.&nbs= p; By assigning the same IPv4 address with non-overlaped port sets to multiple clients, the clients can share the IPv4 address and c= ontinue to deliver IPv4 services to subscribers.
>
>Remember, the do= cument just describes the DHCP option, not the whole lightweight 4over6 wor= k.   If you support working on a draft documenting such an option= , and are willing to start from this work, please say so on the mailing list.   If you think the working group shou= ldn't do this work, or that this draft is the wrong place to start, please = say so on the mailing list.
>
>We will evaluate= working group consensus for adoption on October 24.
>__________________= _____________________________
> dhcwg mailing lis= t > dhcwg at ietf.org
 
 
 
 --_000_8A1B81989BCFAE44A22B2B86BF2B7631893D13867EHE111643EMEA1_-- From xiechf01@gmail.com Tue Oct 16 22:08:14 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D342421F873E for ; Tue, 16 Oct 2012 22:08:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.845 X-Spam-Level: X-Spam-Status: No, score=-1.845 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, 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 4QkbqNWSpPga for ; Tue, 16 Oct 2012 22:08:14 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4E05721F877F for ; Tue, 16 Oct 2012 22:08:14 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id fb11so6589010pad.31 for ; Tue, 16 Oct 2012 22:08:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:reply-to:subject:x-priority:x-has-attach:x-mailer :mime-version:message-id:content-type; bh=JNsHljrvAwtyJREMbPHWeor7s7o5DqYRswaUtenq61w=; b=LQBST1tcl4WTs1xljHARNaOqa0LbfkmNWlWdVbSfow+h774lpisN8hbRo7wI3BNMN7 nubNPnWGDLLGfesyAFaWeXyYvb8fqHQcRE6vbYPQeJjCzWfq+ZxHFIi/E1CxSP3Kb2op aB7g5HL/xJA6wwk9KNWvSV/bbG5vob+UzNDOXDOzvRUkOtJBl0USht3HgVDpiG1B8eBX jPnQXWFbI+F6sEUM1wWsfWMJAiKaFri7CwUj8uLYkMZLaub6m9t51MoRdrprZm9DraQE w5XqfLM9j9mZlNQAPyn2TZMHvVrBC+JzK5fxcCrKyz4JzDczQpBZ7mm6c5TL1Y6frPf1 xsHw== Received: by 10.68.83.68 with SMTP id o4mr53980067pby.25.1350450493957; Tue, 16 Oct 2012 22:08:13 -0700 (PDT) Received: from xiechf-PC ([219.142.69.78]) by mx.google.com with ESMTPS id od2sm11901550pbb.28.2012.10.16.22.07.57 (version=SSLv3 cipher=OTHER); Tue, 16 Oct 2012 22:08:12 -0700 (PDT) Date: Wed, 17 Oct 2012 13:07:54 +0800 From: xiechf01 To: dhcwg , dhcwg X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <201210171307404340951@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart271663135434_=----" X-Mailman-Approved-At: Tue, 16 Oct 2012 22:52:54 -0700 Subject: [dhcwg] Call for adoption: draft-sun-dhc-port-set-option X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: xiechf01 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 05:08:15 -0000 This is a multi-part message in MIME format. ------=_001_NextPart271663135434_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 DQpJIHdvdWxkIGxpa2UgdG8gc3VwcG9ydCB0aGlzIGRvY3VtZW50IGFzIGEgd29yayBpdGVtIG9m IGRoYy4NCg0KQ2hvbmdmZW5nICBYaWUNCg0KDQotLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0N CkRlIDogZGhjd2ctYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmRoY3dnLWJvdW5jZXNAaWV0Zi5v cmddIERlIGxhIHBhcnQgZGUgVGVkIExlbW9uDQpFbnZveaimIDogbWVyY3JlZGkgMTAgb2N0b2Jy ZSAyMDEyIDE1OjMxDQqopCA6IGRoY3dnIFdHDQpPYmpldCA6IFtkaGN3Z10gQ2FsbCBmb3IgYWRv cHRpb246IGRyYWZ0LXN1bi1kaGMtcG9ydC1zZXQtb3B0aW9uDQpUaGUgYXV0aG9ycyBvZiB0aGlz IGRyYWZ0IGhhdmUgYXNrZWQgdGhlIERIQyB3b3JraW5nIGdyb3VwIHRvIGFkb3B0IGl0IGFzIGEg d29yayBpdGVtLg0KDQpUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIG5ldyBESENQdjQgb3B0aW9u IHdoaWNoIGFsbG93cyB0aGUgREhDUHY0IHNlcnZlciB0byBhc3NpZ24gYSBzZXQgb2YgcG9ydHMg dG8gYSB1c2VyIGRldmljZSBkdXJpbmcgdGhlIElQdjQgYWRkcmVzcyBwcm92aXNpb25pbmcgcHJv Y2Vzcy4gIEJ5IGFzc2lnbmluZyB0aGUgc2FtZSBJUHY0IGFkZHJlc3Mgd2l0aCBub24tb3Zlcmxh cGVkIHBvcnQgc2V0cyB0byBtdWx0aXBsZSBjbGllbnRzLCB0aGUgY2xpZW50cyBjYW4gc2hhcmUg dGhlIElQdjQgYWRkcmVzcyBhbmQgY29udGludWUgdG8gZGVsaXZlciBJUHY0IHNlcnZpY2VzIHRv IHN1YnNjcmliZXJzLg0KDQpSZW1lbWJlciwgdGhlIGRvY3VtZW50IGp1c3QgZGVzY3JpYmVzIHRo ZSBESENQIG9wdGlvbiwgbm90IHRoZSB3aG9sZSBsaWdodHdlaWdodCA0b3ZlcjYgd29yay4gICBJ ZiB5b3Ugc3VwcG9ydCB3b3JraW5nIG9uIGEgZHJhZnQgZG9jdW1lbnRpbmcgc3VjaCBhbiBvcHRp b24sIGFuZCBhcmUgd2lsbGluZyB0byBzdGFydCBmcm9tIHRoaXMgd29yaywgcGxlYXNlIHNheSBz byBvbiB0aGUgbWFpbGluZyBsaXN0LiAgIElmIHlvdSB0aGluayB0aGUgd29ya2luZyBncm91cCBz aG91bGRuJ3QgZG8gdGhpcyB3b3JrLCBvciB0aGF0IHRoaXMgZHJhZnQgaXMgdGhlIHdyb25nIHBs YWNlIHRvIHN0YXJ0LCBwbGVhc2Ugc2F5IHNvIG9uIHRoZSBtYWlsaW5nIGxpc3QuDQoNCldlIHdp bGwgZXZhbHVhdGUgd29ya2luZyBncm91cCBjb25zZW5zdXMgZm9yIGFkb3B0aW9uIG9uIE9jdG9i ZXIgMjQuDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K ZGhjd2cgbWFpbGluZyBsaXN0DQpkaGN3Z0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9kaGN3Zw== ------=_001_NextPart271663135434_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
 
I would like to support this document as a work item of dhc.
 
Chongfeng  Xie
 
 
-----Message d'origine-----
De : dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf= .org] De la part de Ted Lemon
Envoy=A8=A6 : mercredi 10 octobre 2012 = 15:31
À : dhcwg WG
Objet : [dhcwg] Call for adoption: draf= t-sun-dhc-port-set-option
The authors of this draft have asked&nb= sp;the DHC working group to adopt it as=  a work item.
 
This document describes a new DHCPv4 op= tion which allows the DHCPv4 server to = assign a set of ports to a user de= vice during the IPv4 address provisioning pr= ocess.  By assigning the same IPv4 addr= ess with non-overlaped port sets to multiple=  clients, the clients can share the IPv= 4 address and continue to deliver IPv4 = services to subscribers.
 
Remember, the document just describes the&nb= sp;DHCP option, not the whole lightweight 4o= ver6 work.   If you support working&nbs= p;on a draft documenting such an option,&nbs= p;and are willing to start from this wo= rk, please say so on the mailing list.&= nbsp;  If you think the working group&n= bsp;shouldn't do this work, or that this&nbs= p;draft is the wrong place to start, pl= ease say so on the mailing list.
 
We will evaluate working group consensus&nbs= p;for adoption on October 24.
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg
------=_001_NextPart271663135434_=------ From cathy.zhou@huawei.com Tue Oct 16 23:57:14 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5087821F8789 for ; Tue, 16 Oct 2012 23:57:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[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 oVb93Ww4-eiR for ; Tue, 16 Oct 2012 23:57:13 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 19C1C21F8787 for ; Tue, 16 Oct 2012 23:57:12 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALS01336; Wed, 17 Oct 2012 06:57:10 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 17 Oct 2012 07:56:00 +0100 Received: from SZXEML440-HUB.china.huawei.com (10.72.61.75) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 17 Oct 2012 14:56:49 +0800 Received: from SZXEML527-MBX.china.huawei.com ([169.254.3.171]) by SZXEML440-HUB.china.huawei.com ([10.72.61.75]) with mapi id 14.01.0323.003; Wed, 17 Oct 2012 14:56:44 +0800 From: "Zhouqian (Cathy)" To: "ian.farrer@telekom.de" , "Ted.Lemon@nominum.com" Thread-Topic: [dhcwg] Call for adoption: draft-sun-dhc-port-set-option Thread-Index: Ac2rV8hmg7L9Z5z0T/+B6okBSRIHVQA3Lw+A Date: Wed, 17 Oct 2012 06:56:43 +0000 Message-ID: References: <8A1B81989BCFAE44A22B2B86BF2B7631893D13867E@HE111643.EMEA1.CDS.T-INTERNAL.COM> In-Reply-To: <8A1B81989BCFAE44A22B2B86BF2B7631893D13867E@HE111643.EMEA1.CDS.T-INTERNAL.COM> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.77.118] Content-Type: multipart/alternative; boundary="_000_A6A061BEE5DDC94A9692D9D81AF776DF2D4DC98Dszxeml527mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-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, 17 Oct 2012 06:57:14 -0000 --_000_A6A061BEE5DDC94A9692D9D81AF776DF2D4DC98Dszxeml527mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1. Best Regards, Cathy From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of i= an.farrer@telekom.de Sent: Tuesday, October 16, 2012 12:36 PM To: Ted.Lemon@nominum.com Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-option I support the adoption of this draft. BR, Ian On Oct 10, 2012, at 6:31 AM, "Ted Lemon" wrote: >The authors of this draft have asked the DHC working group to adopt it as = a work item. > >This document describes a new DHCPv4 option which allows the DHCPv4 server= to assign a set of ports to a user device during the IPv4 address provisio= ning process. By assigning the same IPv4 address with non-overlaped port s= ets to multiple clients, the clients can share the IPv4 address and continu= e to deliver IPv4 services to subscribers. > >Remember, the document just describes the DHCP option, not the whole light= weight 4over6 work. If you support working on a draft documenting such an= option, and are willing to start from this work, please say so on the mail= ing list. If you think the working group shouldn't do this work, or that = this draft is the wrong place to start, please say so on the mailing list. > >We will evaluate working group consensus for adoption on October 24. >_______________________________________________ > dhcwg mailing list > dhcwg at ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg --_000_A6A061BEE5DDC94A9692D9D81AF776DF2D4DC98Dszxeml527mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1.

 = ;

Best Regards,

Cathy

 = ;

From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org= ] On Behalf Of ian.farrer@telekom.de
Sent: Tuesday, October 16, 2012 12:36 PM
To: Ted.Lemon@nominum.com
Cc: dhcwg@ietf.org
Subject: Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-optio= n

 

I support the adoption of this = draft.

BR,

Ian

 

On Oct 10, 2012, at 6:31 AM, &q= uot;Ted Lemon" <Ted.Lemon at nominum.com> wrote:

>The authors of this draft have asked th= e DHC working group to adopt it as a work item.=

> =

>This document describes a new DHCPv4 op= tion which allows the DHCPv4 server to assign a set of ports to a user devi= ce during the IPv4 address provisioning process.  By assigning the same IPv4 address with non-overlaped port sets to multiple c= lients, the clients can share the IPv4 address and continue to deliver IPv4= services to subscribers.

> =

>Remember, the document just describes t= he DHCP option, not the whole lightweight 4over6 work.   If you s= upport working on a draft documenting such an option, and are willing to start from this work, please say so on the mailing list. &= nbsp; If you think the working group shouldn't do this work, or that this d= raft is the wrong place to start, please say so on the mailing list.=

> =

>We will evaluate working group consensu= s for adoption on October 24.=

>___________________________= ____________________

> dhcwg mailing list > dh= cwg at ietf.org

 

 

 

--_000_A6A061BEE5DDC94A9692D9D81AF776DF2D4DC98Dszxeml527mbxchi_-- From tom.taylor.stds@gmail.com Wed Oct 17 06:25:56 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5B4121F8771 for ; Wed, 17 Oct 2012 06:25:56 -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.301, 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 U+0kwC8cDmdO for ; Wed, 17 Oct 2012 06:25:56 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5803421F8759 for ; Wed, 17 Oct 2012 06:25:56 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so13487135iec.31 for ; Wed, 17 Oct 2012 06:25:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-antivirus:x-antivirus-status; bh=pHuQKvTZMmYzgHhSZ+Dsj1NZEw+X2yZ0htU9gBtv36I=; b=xzXsDLMrTjXOi0F1T6TcquXtTvA2EiVtE4DhvlGjuIm3ZsFMW5TaRaWq76SZhB7dZl Url7FiSrCuJWPJRum97jwlKSQEVCcIxNV2Kkd6F8J2FMw2brZFeTlhVG5MZi4e/X4chX RHAFZPdaclpm+Zehb+EpFBI1EPJNB2eateo0t4Yw1+yc/6cIRFpnd74SRKz7Wo0XB+ac LE6y7cbZZEk3Oids6cHJQdkYSnu8U3kJe6nKqDS6sAXAeaubBLoWV2YMkCBCeAVc7OX3 jkKu8iCDkYLNNITCuUs6Q8D4CRYZBPPaYVjLFOYWomXcL//9j3HeIcageHaNnRWZmrZj NkoA== Received: by 10.50.150.144 with SMTP id ui16mr1477305igb.68.1350480355952; Wed, 17 Oct 2012 06:25:55 -0700 (PDT) Received: from [127.0.0.1] ([207.112.101.149]) by mx.google.com with ESMTPS id ch4sm10872362igb.2.2012.10.17.06.25.54 (version=SSLv3 cipher=OTHER); Wed, 17 Oct 2012 06:25:54 -0700 (PDT) Message-ID: <507EB1E3.2010506@gmail.com> Date: Wed, 17 Oct 2012 09:25:55 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Ted Lemon References: <9D3C0AC1-D5B1-4C25-AC47-4D08E3252D54@nominum.com> In-Reply-To: <9D3C0AC1-D5B1-4C25-AC47-4D08E3252D54@nominum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 121017-0, 17/10/2012), Outbound message X-Antivirus-Status: Clean Cc: dhcwg WG Subject: Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-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, 17 Oct 2012 13:25:57 -0000 This is needed. I support it. On 10/10/2012 9:30 AM, Ted Lemon wrote: > The authors of this draft have asked the DHC working group to adopt it as a work item. > > This document describes a new DHCPv4 option which allows the DHCPv4 server to assign a set of ports to a user device during the IPv4 address provisioning process. By assigning the same IPv4 address with non-overlaped port sets to multiple clients, the clients can share the IPv4 address and continue to deliver IPv4 services to subscribers. > > Remember, the document just describes the DHCP option, not the whole lightweight 4over6 work. If you support working on a draft documenting such an option, and are willing to start from this work, please say so on the mailing list. If you think the working group shouldn't do this work, or that this draft is the wrong place to start, please say so on the mailing list. > > We will evaluate working group consensus for adoption on October 24. > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > From Olaf.Bonness@telekom.de Wed Oct 17 06:27:24 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26A4421F8771 for ; Wed, 17 Oct 2012 06:27:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 7ji7cVMV0-NO for ; Wed, 17 Oct 2012 06:27:23 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by ietfa.amsl.com (Postfix) with ESMTP id 39A1921F8759 for ; Wed, 17 Oct 2012 06:27:23 -0700 (PDT) Received: from he111527.emea1.cds.t-internal.com ([10.125.90.86]) by tcmail81.telekom.de with ESMTP/TLS/AES128-SHA; 17 Oct 2012 15:27:21 +0200 Received: from HE113605.emea1.cds.t-internal.com ([169.254.1.201]) by HE111527.EMEA1.CDS.T-INTERNAL.COM ([2002:7cd:5a56::7cd:5a56]) with mapi; Wed, 17 Oct 2012 15:27:20 +0200 From: To: , Date: Wed, 17 Oct 2012 15:27:19 +0200 Thread-Topic: [dhcwg] Call for adoption: draft-sun-dhc-port-set-option Thread-Index: Ac2savrW3YesHoRQSROGLGTbxt8YlQAABEmQ Message-ID: References: <9D3C0AC1-D5B1-4C25-AC47-4D08E3252D54@nominum.com> <507EB1E3.2010506@gmail.com> In-Reply-To: <507EB1E3.2010506@gmail.com> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-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, 17 Oct 2012 13:27:24 -0000 Support. -----Urspr=FCngliche Nachricht----- Von: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] Im Auftrag von = Tom Taylor Gesendet: Mittwoch, 17. Oktober 2012 15:26 An: Ted Lemon Cc: dhcwg WG Betreff: Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-option This is needed. I support it. On 10/10/2012 9:30 AM, Ted Lemon wrote: > The authors of this draft have asked the DHC working group to adopt it as= a work item. > > This document describes a new DHCPv4 option which allows the DHCPv4 serve= r to assign a set of ports to a user device during the IPv4 address provisi= oning process. By assigning the same IPv4 address with non-overlaped port = sets to multiple clients, the clients can share the IPv4 address and contin= ue to deliver IPv4 services to subscribers. > > Remember, the document just describes the DHCP option, not the whole ligh= tweight 4over6 work. If you support working on a draft documenting such a= n option, and are willing to start from this work, please say so on the mai= ling list. If you think the working group shouldn't do this work, or that= this draft is the wrong place to start, please say so on the mailing list. > > We will evaluate working group consensus for adoption on October 24. > _______________________________________________ > 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 otroan@employees.org Wed Oct 17 10:52:47 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E170521F8625 for ; Wed, 17 Oct 2012 10:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.221 X-Spam-Level: X-Spam-Status: No, score=-10.221 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 0jkV+RO66SZb for ; Wed, 17 Oct 2012 10:52:47 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id CF7EA21F861F for ; Wed, 17 Oct 2012 10:52:46 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EADDvflCQ/khN/2dsb2JhbABFwCaBCIIgAQEBAwESAQodNAsFCwtGVwYuB4dcBgubQKAqkTpgA5cAhE2IZ4FrgnE X-IronPort-AV: E=Sophos;i="4.80,602,1344211200"; d="scan'208";a="8894428" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-4.cisco.com with ESMTP; 17 Oct 2012 17:52:45 +0000 Received: from [10.61.101.94] (dhcp-10-61-101-94.cisco.com [10.61.101.94]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q9HHqjod018161 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 17 Oct 2012 17:52:45 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <9D3C0AC1-D5B1-4C25-AC47-4D08E3252D54@nominum.com> Date: Wed, 17 Oct 2012 19:52:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9D3C0AC1-D5B1-4C25-AC47-4D08E3252D54@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1498) Cc: dhcwg WG Subject: Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-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, 17 Oct 2012 17:52:48 -0000 > The authors of this draft have asked the DHC working group to adopt it = as a work item. >=20 > This document describes a new DHCPv4 option which allows the DHCPv4 = server to assign a set of ports to a user device during the IPv4 address = provisioning process. By assigning the same IPv4 address with = non-overlaped port sets to multiple clients, the clients can share the = IPv4 address and continue to deliver IPv4 services to subscribers. >=20 > Remember, the document just describes the DHCP option, not the whole = lightweight 4over6 work. If you support working on a draft documenting = such an option, and are willing to start from this work, please say so = on the mailing list. If you think the working group shouldn't do this = work, or that this draft is the wrong place to start, please say so on = the mailing list. what about this draft? http://tools.ietf.org/html/draft-wu-dhc-port-set-option-00=20 the MAP effort is using a different port algorithm, with a DHCPV6 option = specified here: = http://tools.ietf.org/html/draft-mdt-softwire-map-dhcp-option-03#section-4= .4 do we need 2,3,4 DHCP options for all of this variants? softwire went through quite an exercise to decide on a port allocation = scheme for the stateless solutions. I'm not sure I see the justification for using a different algorithm for = "configured" A+P tunnels. I think it is premature to adopt this in DHC (I'm not against defining = an option for this, but _this_ isn't defined yet). cheers, Ole From tom.taylor.stds@gmail.com Wed Oct 17 11:07:30 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4227C21F8661 for ; Wed, 17 Oct 2012 11:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.348 X-Spam-Level: X-Spam-Status: No, score=-3.348 tagged_above=-999 required=5 tests=[AWL=0.251, 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 K0RqQ0vucYY7 for ; Wed, 17 Oct 2012 11:07:29 -0700 (PDT) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 706D421F84D3 for ; Wed, 17 Oct 2012 11:07:29 -0700 (PDT) Received: by mail-ia0-f172.google.com with SMTP id o25so6521826iad.31 for ; Wed, 17 Oct 2012 11:07:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding:x-antivirus :x-antivirus-status; bh=wE1CFN1rsk7ndn9M0AxCdE/bm5EQ2/tEOt+Nu4Q6JTE=; b=0J0qOsy7rh2JsBTncRjkwYg5srq3+0s2O04th6Nl+ogjYHFcOFFogbux2Epry7fZWO 3i7/jyA9eg8SWSHD4GWEwxQAnwJaZ/Z/6NJUNXBiRqniZgAB5ctyvYnNdMxW8Cb0fDHg voCvSJdS1BftFnJspGy0m6t9rfhfxTfzxMaGHKvIYp7gRXL6ckUwrxWv9mAszU30jVKG 6/jTV2+GP3iltHtTnSehXFCrHuOEcS6dtGQMLxEvbKJExBi8wmR4056T5RpMuSbK2rEj UvkN7IgUerB1V/gR7sGOgJDo8KCh/ZWDIFOwn03I/si07Nqrcu79X/rgSgISBFvqr9ju Eqqw== Received: by 10.50.178.67 with SMTP id cw3mr2393229igc.53.1350497248832; Wed, 17 Oct 2012 11:07:28 -0700 (PDT) Received: from [127.0.0.1] ([207.112.101.149]) by mx.google.com with ESMTPS id xn10sm10637562igb.4.2012.10.17.11.07.26 (version=SSLv3 cipher=OTHER); Wed, 17 Oct 2012 11:07:28 -0700 (PDT) Message-ID: <507EF3DB.7080608@gmail.com> Date: Wed, 17 Oct 2012 14:07:23 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: dhcwg@ietf.org References: <9D3C0AC1-D5B1-4C25-AC47-4D08E3252D54@nominum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 121017-1, 17/10/2012), Outbound message X-Antivirus-Status: Clean Subject: Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-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, 17 Oct 2012 18:07:30 -0000 Rather obviously, the Wu draft was superseded by the present one. On 17/10/2012 1:52 PM, Ole Trøan wrote: >> The authors of this draft have asked the DHC working group to adopt it as a work item. ... > > what about this draft? > http://tools.ietf.org/html/draft-wu-dhc-port-set-option-00 > > the MAP effort is using a different port algorithm, with a DHCPV6 option specified here: > http://tools.ietf.org/html/draft-mdt-softwire-map-dhcp-option-03#section-4.4 ... From otroan@employees.org Wed Oct 17 11:13:15 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0A9F21F86A1 for ; Wed, 17 Oct 2012 11:13:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.23 X-Spam-Level: X-Spam-Status: No, score=-10.23 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 CIaOt8M9SCPz for ; Wed, 17 Oct 2012 11:13:15 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 149D421F84EB for ; Wed, 17 Oct 2012 11:13:14 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao0FABn0flCQ/khL/2dsb2JhbABFhUu6W4EIgiABAQEDAQEBAQ8BClELBQsLGC4nMAYTIodcBgubRaAqi1iFYmADlwCETYhngWuCcQ X-IronPort-AV: E=Sophos;i="4.80,602,1344211200"; d="scan'208";a="145429206" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 17 Oct 2012 18:13:13 +0000 Received: from [10.61.101.94] (dhcp-10-61-101-94.cisco.com [10.61.101.94]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9HIDC9Z012288 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 17 Oct 2012 18:13:13 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <507EF3DB.7080608@gmail.com> Date: Wed, 17 Oct 2012 20:13:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9D3C0AC1-D5B1-4C25-AC47-4D08E3252D54@nominum.com> <507EF3DB.7080608@gmail.com> To: Tom Taylor X-Mailer: Apple Mail (2.1498) Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-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, 17 Oct 2012 18:13:15 -0000 Tom, > Rather obviously, the Wu draft was superseded by the present one. what about the other questions? why this style of port mapping as opposed the any other? in particular = one that has consensus in softwires already... cheers, Ole >=20 > On 17/10/2012 1:52 PM, Ole Tr=F8an wrote: >>> The authors of this draft have asked the DHC working group to adopt = it as a work item. > ... >=20 >>=20 >> what about this draft? >> http://tools.ietf.org/html/draft-wu-dhc-port-set-option-00 >>=20 >> the MAP effort is using a different port algorithm, with a DHCPV6 = option specified here: >> = http://tools.ietf.org/html/draft-mdt-softwire-map-dhcp-option-03#section-4= .4 > ... > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From Ted.Lemon@nominum.com Wed Oct 17 11:59:46 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B6C221F8602 for ; Wed, 17 Oct 2012 11:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.33 X-Spam-Level: X-Spam-Status: No, score=-106.33 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 xrIzHGkliADx for ; Wed, 17 Oct 2012 11:59:45 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id 6288221F85EF for ; Wed, 17 Oct 2012 11:59:45 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKUH8AIGkRSEpcUmWu3oaoC1ekqrPpUFKT@postini.com; Wed, 17 Oct 2012 11:59:45 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 A3F361B8347 for ; Wed, 17 Oct 2012 11:59:43 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 99E2519005C; Wed, 17 Oct 2012 11:59:43 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Wed, 17 Oct 2012 11:59:43 -0700 From: Ted Lemon To: =?Windows-1252?Q?Ole_Tr=F8an?= Thread-Topic: [dhcwg] Call for adoption: draft-sun-dhc-port-set-option Thread-Index: AQHNput68Hhly3n5akOtNZsf4t9jOpe+R+0AgAAEGICAAAGgAIAADP4A Date: Wed, 17 Oct 2012 18:59:43 +0000 Message-ID: <5715F968-7CF0-4AD6-A622-A5151827D23B@nominum.com> References: <9D3C0AC1-D5B1-4C25-AC47-4D08E3252D54@nominum.com> <507EF3DB.7080608@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <5E9F5B1C8958094FAAA8A49ACDF4C547@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-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, 17 Oct 2012 18:59:46 -0000 On Oct 17, 2012, at 2:13 PM, Ole Tr=F8an wrote: > why this style of port mapping as opposed the any other? in particular on= e that has consensus in softwires already... There seems to be a lot of effort going into fancy port mapping algorithms = which do not make an attacker's job noticeably harder. The decision here = was to simply map out a contiguous range, and allow the gateway to do port = randomization within that range. It is understood that the effectiveness = of port range randomization goes down as the port range grows smaller, but = it's also understood that there isn't anything we can actually do about thi= s=97address sharing unavoidably makes guessing ports easier. Any deterministic algorithm that isn't a straightforward port range simply = adds complexity without adding benefit: there's nothing secret about it=97a= n attacker can just reverse it, and there is no way to keep secret from the= attacker what algorithm has been chosen. Consequently these alternative = algorithms were removed from consideration. Seeded random number algorithms were discussed, but implementation was cons= idered unlikely, and so it was decided that they weren't worth bothering wi= th. My own conversations with service providers have indicated a strong p= reference for simplicity here to avoid interoperability problems when imple= mentations accidentally differ. The MAP folks should just use port ranges. There is no need for them to d= o their own port set allocation option. From otroan@employees.org Wed Oct 17 13:23:12 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC74421F86B1 for ; Wed, 17 Oct 2012 13:23:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.237 X-Spam-Level: X-Spam-Status: No, score=-10.237 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 IeMbY6FXajV1 for ; Wed, 17 Oct 2012 13:23:09 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 70FEC21F8698 for ; Wed, 17 Oct 2012 13:23:09 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EALsSf1CQ/khL/2dsb2JhbABFwCiBCIIgAQEBAwESAQpcBQsLRlcGNYdcBgubbKA3kTpgA4s+i0KETW6HeYFrgnE X-IronPort-AV: E=Sophos;i="4.80,602,1344211200"; d="scan'208";a="8887575" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-3.cisco.com with ESMTP; 17 Oct 2012 20:23:08 +0000 Received: from [10.61.101.94] (dhcp-10-61-101-94.cisco.com [10.61.101.94]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9HKN70F007991 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 17 Oct 2012 20:23:08 GMT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: =?windows-1252?Q?Ole_Tr=F8an?= In-Reply-To: <5715F968-7CF0-4AD6-A622-A5151827D23B@nominum.com> Date: Wed, 17 Oct 2012 22:23:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4A947FFD-C1B2-4B63-A787-C27D78A33F24@employees.org> References: <9D3C0AC1-D5B1-4C25-AC47-4D08E3252D54@nominum.com> <507EF3DB.7080608@gmail.com> <5715F968-7CF0-4AD6-A622-A5151827D23B@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1498) Cc: "" Subject: Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-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, 17 Oct 2012 20:23:12 -0000 Ted, >> why this style of port mapping as opposed the any other? in = particular one that has consensus in softwires already... >=20 > There seems to be a lot of effort going into fancy port mapping = algorithms which do not make an attacker's job noticeably harder. The = decision here was to simply map out a contiguous range, and allow the = gateway to do port randomization within that range. It is understood = that the effectiveness of port range randomization goes down as the port = range grows smaller, but it's also understood that there isn't anything = we can actually do about this=97address sharing unavoidably makes = guessing ports easier. the port mapping algorithm I'm talking about = (http://tools.ietf.org/html/draft-ietf-softwire-map-02) is a) not fancy b) does not do any port randomization. which one are you referring to? > Any deterministic algorithm that isn't a straightforward port range = simply adds complexity without adding benefit: there's nothing secret = about it=97an attacker can just reverse it, and there is no way to keep = secret from the attacker what algorithm has been chosen. Consequently = these alternative algorithms were removed from consideration. in agreement with you there. which ones did you remove? > Seeded random number algorithms were discussed, but implementation was = considered unlikely, and so it was decided that they weren't worth = bothering with. My own conversations with service providers have = indicated a strong preference for simplicity here to avoid = interoperability problems when implementations accidentally differ. agree. > The MAP folks should just use port ranges. There is no need for them = to do their own port set allocation option. they do just use port ranges. please read the proposal. why do you want to standardize yet another representation of port = ranges? if you have to, do it in softwires (and don't use discontiguous = masks). cheers, Ole= From Ted.Lemon@nominum.com Wed Oct 17 18:52:34 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B974A1F0417 for ; Wed, 17 Oct 2012 18:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.329 X-Spam-Level: X-Spam-Status: No, score=-106.329 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 HpbG9-zjwko4 for ; Wed, 17 Oct 2012 18:52:34 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 09E4F1F0381 for ; Wed, 17 Oct 2012 18:52:34 -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 DSNKUH9g4VvhJ4UdHO0QbagzA79+bo9f6pRi@postini.com; Wed, 17 Oct 2012 18:52:34 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 303971B8345 for ; Wed, 17 Oct 2012 18:52:33 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 250A719005C; Wed, 17 Oct 2012 18:52:33 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Wed, 17 Oct 2012 18:52:33 -0700 From: Ted Lemon To: =?Windows-1252?Q?Ole_Tr=F8an?= Thread-Topic: [dhcwg] Call for adoption: draft-sun-dhc-port-set-option Thread-Index: AQHNput68Hhly3n5akOtNZsf4t9jOpe+R+0AgAAEGICAAAGgAIAADP4AgAAXToCAAFwIgA== Date: Thu, 18 Oct 2012 01:52:32 +0000 Message-ID: References: <9D3C0AC1-D5B1-4C25-AC47-4D08E3252D54@nominum.com> <507EF3DB.7080608@gmail.com> <5715F968-7CF0-4AD6-A622-A5151827D23B@nominum.com> <4A947FFD-C1B2-4B63-A787-C27D78A33F24@employees.org> In-Reply-To: <4A947FFD-C1B2-4B63-A787-C27D78A33F24@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-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, 18 Oct 2012 01:52:34 -0000 On Oct 17, 2012, at 4:23 PM, Ole Tr=F8an wrote: > the port mapping algorithm I'm talking about (http://tools.ietf.org/html/= draft-ietf-softwire-map-02) is > a) not fancy > b) does not do any port randomization. >=20 > which one are you referring to? I haven't read that draft=97I'm referring to the two drafts that were merge= d to produce the current draft, to which you are objecting. The port rand= omization is done on the gateway, and is not part of the port set option=97= it's just the standard port randomization algorithm we've been using for ye= ars, only with a smaller set of ports to choose from. I don't think the n= ew documents even specify the algorithm, since it's not new. > in agreement with you there. which ones did you remove? I didn't remove any. > they do just use port ranges. please read the proposal. >=20 > why do you want to standardize yet another representation of port ranges?= if you have to, do it in softwires (and don't use discontiguous masks). I want there to be one DHCP option that is used by all address-sharing solu= tions. If you think this option is the wrong option, by all means propose= changes. Softwires is no better a place to work on this option than dhc= ; as a regular participant in dhc, it seems to me that it's equally conveni= ent for you either way. It's also my understanding that Qi Sun et al. are= doing this work as part of a larger effort that is taking place in softwir= es. Honestly, I'm not that up on the details of the debate in softwires. It w= as my understanding that a resolution had been reached, and that the lightw= eight 4over6 draft that Qi Sun, et al., have been working on was adopted. = If this is not the case, I am interested to know. But this is not the first time that you've objected to drafts that purport = to solve DHCP-related problems as part of that softwires work. When I've = asked you before, you haven't responded by telling me that my understanding= of the situation in softwires is incorrect. If it _is_ incorrect, please= do tell me in what way it is incorrect, so that I can stop laboring under = false assumptions.= From otroan@employees.org Thu Oct 18 00:16:17 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C09E21F85B4 for ; Thu, 18 Oct 2012 00:16:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.243 X-Spam-Level: X-Spam-Status: No, score=-10.243 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 1FzeUJDQPKOQ for ; Thu, 18 Oct 2012 00:16:16 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 2924A21F859E for ; Thu, 18 Oct 2012 00:16:15 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAFOsf1CQ/khL/2dsb2JhbABFwEOBCIIgAQEBAwESAQpODgULC0ZXBi4Hh1wGC5t8oCSROmADiz6LQoU7h3mBa4Jx X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="8906210" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-4.cisco.com with ESMTP; 18 Oct 2012 07:16:14 +0000 Received: from dhcp-lys01-vla250-10-147-112-212.cisco.com (dhcp-lys01-vla250-10-147-112-212.cisco.com [10.147.112.212]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9I7GDvZ030375 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 18 Oct 2012 07:16:14 GMT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: =?windows-1252?Q?Ole_Tr=F8an?= In-Reply-To: Date: Thu, 18 Oct 2012 09:16:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9D3C0AC1-D5B1-4C25-AC47-4D08E3252D54@nominum.com> <507EF3DB.7080608@gmail.com> <5715F968-7CF0-4AD6-A622-A5151827D23B@nominum.com> <4A947FFD-C1B2-4B63-A787-C27D78A33F24@employees.org> To: Ted Lemon X-Mailer: Apple Mail (2.1498) Cc: "" Subject: Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-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, 18 Oct 2012 07:16:17 -0000 Ted, >> the port mapping algorithm I'm talking about = (http://tools.ietf.org/html/draft-ietf-softwire-map-02) is >> a) not fancy >> b) does not do any port randomization. >>=20 >> which one are you referring to? >=20 > I haven't read that draft=97I'm referring to the two drafts that were = merged to produce the current draft, to which you are objecting. The = port randomization is done on the gateway, and is not part of the port = set option=97it's just the standard port randomization algorithm we've = been using for years, only with a smaller set of ports to choose from. = I don't think the new documents even specify the algorithm, since it's = not new. the algorithm I'm talking about is the one for choosing the port set. = not about how the outside NAT randomly chooses source ports from the = given port set. >> in agreement with you there. which ones did you remove? >=20 > I didn't remove any. earlier in the thread you said the following: "Any deterministic algorithm that isn't a straightforward port range = simply =3D adds complexity without adding benefit: there's nothing secret about = it=3D97a=3D n attacker can just reverse it, and there is no way to keep secret = from the=3D attacker what algorithm has been chosen. Consequently these = alternative =3D algorithms were removed from consideration." at least I read the last sentence to imply that you had done a = evaluation of different algorithms and removed some. please see = http://tools.ietf.org/html/draft-boucadair-behave-ipv6-portrange-04 for an analysis of the various proposals. >> they do just use port ranges. please read the proposal. >>=20 >> why do you want to standardize yet another representation of port = ranges? if you have to, do it in softwires (and don't use discontiguous = masks). >=20 > I want there to be one DHCP option that is used by all address-sharing = solutions. If you think this option is the wrong option, by all means = propose changes. Softwires is no better a place to work on this = option than dhc; as a regular participant in dhc, it seems to me that = it's equally convenient for you either way. It's also my understanding = that Qi Sun et al. are doing this work as part of a larger effort that = is taking place in softwires. there is already consensus in softwires on a port mapping algorithm. = that is specified in http://tools.ietf.org/html/draft-ietf-softwire-map-02#section-5 with the corresponding DHCPv6 option in: http://tools.ietf.org/html/draft-ietf-softwire-map-dhcp-01#section-4.4 softwire has worked for a long time on port mapping, and it doesn't seem = sensible to me that DHC should redo all those decisions and acquire the = expertise already there. we _could_ standardize different port mapping algorithms for DHCPv4 and = DHCPv6, or different ones for the plethora of A+P type mechanisms, but = I'm at least aren't convinced that we need more than one simple scheme. > Honestly, I'm not that up on the details of the debate in softwires. = It was my understanding that a resolution had been reached, and that the = lightweight 4over6 draft that Qi Sun, et al., have been working on was = adopted. If this is not the case, I am interested to know. as far as I can see (http://datatracker.ietf.org/wg/softwire/) = Lightweight 4over6 is not adopted by the working group. > But this is not the first time that you've objected to drafts that = purport to solve DHCP-related problems as part of that softwires work. = When I've asked you before, you haven't responded by telling me that my = understanding of the situation in softwires is incorrect. If it _is_ = incorrect, please do tell me in what way it is incorrect, so that I can = stop laboring under false assumptions. I am pretty sure that your understanding of the situation in softwires = is incorrect. (I'm also pretty sure that my understanding of the situation in = softwires is incorrect. ;-)) may I suggest that the DHC and softwire chairs get together and get a = common understanding? cheers, Ole From wdec.ietf@gmail.com Thu Oct 18 01:03:56 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8A2421F8510 for ; Thu, 18 Oct 2012 01:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.984 X-Spam-Level: X-Spam-Status: No, score=-2.984 tagged_above=-999 required=5 tests=[AWL=0.614, 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 Q6Abfh17gLs2 for ; Thu, 18 Oct 2012 01:03:51 -0700 (PDT) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id A270F21F8507 for ; Thu, 18 Oct 2012 01:03:50 -0700 (PDT) Received: by mail-ea0-f172.google.com with SMTP id k13so2227404eaa.31 for ; Thu, 18 Oct 2012 01:03:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=++s/Bzm2Rn4035+4YgWTP3j5sDdIeoNN38F0BSYOTWE=; b=n4F5/w5onMCpMuubj8Ba1kukSkS8BpKc0scMqo7Zu8I3DmVtpRWPVLxuBAFS72fUBb M4H/iJ4Cv1AFRr2UevjbeNR8ERx4KfmLNNtP0EP4qpJC+VzB8x1p4y2OOrM++t0gkE45 a6o/BOZD4+24sXlyXnTlto4fRoRDXdFp4022eEm8GHh/XnNKPQ7PxJ+y7zf/mopUmTUM jCzv6kPqKzzdn+jwYuTWw9BBhfX7WmBhN/D9hPq4TEjQyiVWyVpxBE2Xhq+IHRK0zZN1 Z1LniXqA/2IdoP2hJAnCNzGe0zUoqtIe6RHE19g7+6pvRnWRqw99xWMqezl79u+P68sI LllA== MIME-Version: 1.0 Received: by 10.14.207.9 with SMTP id m9mr30088602eeo.5.1350547429725; Thu, 18 Oct 2012 01:03:49 -0700 (PDT) Received: by 10.14.128.71 with HTTP; Thu, 18 Oct 2012 01:03:49 -0700 (PDT) In-Reply-To: <9D3C0AC1-D5B1-4C25-AC47-4D08E3252D54@nominum.com> References: <9D3C0AC1-D5B1-4C25-AC47-4D08E3252D54@nominum.com> Date: Thu, 18 Oct 2012 10:03:49 +0200 Message-ID: From: Wojciech Dec To: Ted Lemon Content-Type: multipart/alternative; boundary=047d7b33dc30cd1b2c04cc50d372 Cc: dhcwg WG Subject: Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-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, 18 Oct 2012 08:03:56 -0000 --047d7b33dc30cd1b2c04cc50d372 Content-Type: text/plain; charset=ISO-8859-1 Hi, this option cannot be used to extend regular IPv4 clients or DHCP servers to serve on plain IPv4-only networks, ie it fits into a wider solution/architecture context which is not being covered by the DHC WG. While acknowledging that "some option" needs to be defined, defining it in DHC seems like not the right approach. Furthermore, there are several overlapping solutions here, which can be addressed by a common DHCP spec. Rather interestingly http://tools.ietf.org/html/draft-wu-dhc-port-set-option-00 was a step in the right direction, with draft-sun-dhc-port-set-option regressing. As such I do not support the adoption of this draft. Regards, Woj. On 10 October 2012 15:30, Ted Lemon wrote: > The authors of this draft have asked the DHC working group to adopt it as > a work item. > > This document describes a new DHCPv4 option which allows the DHCPv4 server > to assign a set of ports to a user device during the IPv4 address > provisioning process. By assigning the same IPv4 address with > non-overlaped port sets to multiple clients, the clients can share the IPv4 > address and continue to deliver IPv4 services to subscribers. > > Remember, the document just describes the DHCP option, not the whole > lightweight 4over6 work. If you support working on a draft documenting > such an option, and are willing to start from this work, please say so on > the mailing list. If you think the working group shouldn't do this work, > or that this draft is the wrong place to start, please say so on the > mailing list. > > We will evaluate working group consensus for adoption on October 24. > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > --047d7b33dc30cd1b2c04cc50d372 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

this option cannot be used to extend regular IPv4 clients or DHC= P servers to serve on plain IPv4-only networks, ie it fits into a wider sol= ution/architecture context which is not being covered by the DHC WG. While = acknowledging that "some option" needs to be defined, defining it= in DHC seems like not the right approach. Furthermore, there are several o= verlapping solutions here, which can be addressed by a common DHCP spec. Rather interestingly http://tools.ietf.org/html/draft-wu-dhc-= port-set-option-00 was a step in the right direction, with draft-sun-dh= c-port-set-option regressing.

As such I do not support the adoption of this draft.

Regards,Woj.

On 10 October 2012 15:30, Ted Lemon= <Ted.Lemon@nominum.com> wrote:
The authors of this draft have asked the DHC= working group to adopt it as a work item.

This document describes a new DHCPv4 option which allows the DHCPv4 server = to assign a set of ports to a user device during the IPv4 address provision= ing process. =A0By assigning the same IPv4 address with non-overlaped port = sets to multiple clients, the clients can share the IPv4 address and contin= ue to deliver IPv4 services to subscribers.

Remember, the document just describes the DHCP option, not the whole lightw= eight 4over6 work. =A0 If you support working on a draft documenting such a= n option, and are willing to start from this work, please say so on the mai= ling list. =A0 If you think the working group shouldn't do this work, o= r that this draft is the wrong place to start, please say so on the mailing= list.

We will evaluate working group consensus for adoption on October 24.
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dhcwg

--047d7b33dc30cd1b2c04cc50d372-- From ales.vizdal@t-mobile.cz Thu Oct 18 03:20:01 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E371F21F858E for ; Thu, 18 Oct 2012 03:20:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.696 X-Spam-Level: X-Spam-Status: No, score=-0.696 tagged_above=-999 required=5 tests=[AWL=1.254, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, 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 Oc+6txcdTI1N for ; Thu, 18 Oct 2012 03:20:01 -0700 (PDT) Received: from mailhub1.t-mobile.cz (mailhub1.t-mobile.cz [62.141.0.149]) by ietfa.amsl.com (Postfix) with ESMTP id 1C92421F8589 for ; Thu, 18 Oct 2012 03:20:01 -0700 (PDT) Received: from srvhk504.rdm.cz (unknown [10.254.92.81]) by mailhub1.t-mobile.cz (Postfix) with ESMTP id DD1D1285C3A; Thu, 18 Oct 2012 12:19:59 +0200 (CEST) Received: from SRVHKE02.rdm.cz ([fe80::94ce:8456:f6fa:86a8]) by srvhk504.rdm.cz ([fe80::506:b9a6:d353:9494%12]) with mapi; Thu, 18 Oct 2012 12:19:59 +0200 From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: Ted Lemon , dhcwg WG Date: Thu, 18 Oct 2012 12:20:01 +0200 Thread-Topic: Call for adoption: draft-sun-dhc-port-set-option Thread-Index: AQHNput68Hhly3n5akOtNZsf4t9jOpe+5h+w Message-ID: <1808340F7EC362469DDFFB112B37E2FCC6CF29364C@SRVHKE02.rdm.cz> References: <9D3C0AC1-D5B1-4C25-AC47-4D08E3252D54@nominum.com> In-Reply-To: <9D3C0AC1-D5B1-4C25-AC47-4D08E3252D54@nominum.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="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forwarded Subject: Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-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, 18 Oct 2012 10:20:02 -0000 I support this document. Best Regards, Ales > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of= Ted > Lemon > Sent: Wednesday, October 10, 2012 3:31 PM > To: dhcwg WG > Subject: [dhcwg] Call for adoption: draft-sun-dhc-port-set-option >=20 > The authors of this draft have asked the DHC working group to adopt it as= a work item. >=20 > This document describes a new DHCPv4 option which allows the DHCPv4 serve= r to > assign a set of ports to a user device during the IPv4 address provisioni= ng process. By > assigning the same IPv4 address with non-overlaped port sets to multiple = clients, the > clients can share the IPv4 address and continue to deliver IPv4 services = to subscribers. >=20 > Remember, the document just describes the DHCP option, not the whole ligh= tweight > 4over6 work. If you support working on a draft documenting such an opti= on, and are > willing to start from this work, please say so on the mailing list. If = you think the > working group shouldn't do this work, or that this draft is the wrong pla= ce to start, > please say so on the mailing list. >=20 > We will evaluate working group consensus for adoption on October 24. > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From Ted.Lemon@nominum.com Thu Oct 18 05:24:48 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF8A21F866E for ; Thu, 18 Oct 2012 05:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.479 X-Spam-Level: X-Spam-Status: No, score=-106.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 2GFXEttLdAuz for ; Thu, 18 Oct 2012 05:24:47 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id 1EAFC21F8507 for ; Thu, 18 Oct 2012 05:24:45 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKUH/1DYSj3qpkFxA0gzDU/nu8uzZNC8zM@postini.com; Thu, 18 Oct 2012 05:24:46 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 3AA541B8350 for ; Thu, 18 Oct 2012 05:24:45 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 2D52C19005C for ; Thu, 18 Oct 2012 05:24:45 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Thu, 18 Oct 2012 05:24:45 -0700 From: Ted Lemon To: " WG" Thread-Topic: Volunteers to review draft-ietf-softwire-multicast-prefix-option-02.txt? Thread-Index: AQHNrSuN7cjYEIegMEC1weKrQzCzFQ== Date: Thu, 18 Oct 2012 12:24:44 +0000 Message-ID: References: <94C682931C08B048B7A8645303FDC9F36E64431C88@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dhcwg] Volunteers to review draft-ietf-softwire-multicast-prefix-option-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, 18 Oct 2012 12:24:48 -0000 This is a DHCPv6 option for carrying IPv4-Embedded multicast and unicast IP= v6 prefixes. The DHC working group should review this document for correc= tness with respect to the DHCP option specification. Can I get a few volu= nteers to give this a careful read to make sure the DHCP specification lang= uage is correct? Begin forwarded message: > From: > Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-multicast-prefix= -option-02.txt > Date: October 18, 2012 1:37:48 AM EDT >=20 > We believe this version is ready for a WGLC. >=20 > Cheers, > Med >=20 >=20 >> -----Message d'origine----- >> De : softwires-bounces@ietf.org=20 >> [mailto:softwires-bounces@ietf.org] De la part de=20 >> internet-drafts@ietf.org >> Envoy=E9 : mardi 16 octobre 2012 17:03 >> =C0 : i-d-announce@ietf.org >> Cc : softwires@ietf.org >> Objet : [Softwires] I-D Action:=20 >> draft-ietf-softwire-multicast-prefix-option-02.txt >>=20 >>=20 >> A New Internet-Draft is available from the on-line=20 >> Internet-Drafts directories. >> This draft is a work item of the Softwires Working Group of the IETF. >>=20 >> Title : DHCPv6 Option for IPv4-Embedded=20 >> Multicast and Unicast IPv6 Prefixes >> Author(s) : Mohamed Boucadair >> Jacni Qin >> Tina Tsou >> Xiaohong Deng >> Filename :=20 >> draft-ietf-softwire-multicast-prefix-option-02.txt >> Pages : 7 >> Date : 2012-10-16 >>=20 >> Abstract: >> This document defines Dynamic Host Configuration Protocol version 6 >> (DHCPv6) Option for multicast transition solutions, aiming to convey >> the IPv6 prefixes to be used to build unicast and multicast IPv4- >> embedded IPv6 addresses. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-softwire-multicast- >> prefix-option >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-softwire-multicast-prefix >> -option-02 >>=20 >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-multicast- >> prefix-option-02 >>=20 >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >>=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From Ted.Lemon@nominum.com Thu Oct 18 05:33:21 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88AC721F8720 for ; Thu, 18 Oct 2012 05:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.481 X-Spam-Level: X-Spam-Status: No, score=-106.481 tagged_above=-999 required=5 tests=[AWL=0.118, 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 2Xb3ht2RCTvh for ; Thu, 18 Oct 2012 05:33:20 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id F369421F871E for ; Thu, 18 Oct 2012 05:33:18 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKUH/3DmdiAvLB3eB/T9fjHHedu5pI+Z22@postini.com; Thu, 18 Oct 2012 05:33:19 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 3A3DA1B8350 for ; Thu, 18 Oct 2012 05:33:18 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 31BB719005C for ; Thu, 18 Oct 2012 05:33:18 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Thu, 18 Oct 2012 05:33:18 -0700 From: Ted Lemon To: " WG" Thread-Topic: Call for Agenda Items for IETF 85 Thread-Index: AQHNrSzAWipHGI0lGEuQGqDJlDmLCg== Date: Thu, 18 Oct 2012 12:33:18 +0000 Message-ID: <2642448B-3789-4D93-93BE-90AB36C081D7@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dhcwg] Call for Agenda Items for IETF 85 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, 18 Oct 2012 12:33:21 -0000 Folks, if you plan on presenting anything to the working group in Atlanta, = please send us your agenda items ASAP. We would like to have your slides= by the 31st of October. From volz@cisco.com Thu Oct 18 05:33:38 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65A9D21F8448; Thu, 18 Oct 2012 05:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.26 X-Spam-Level: X-Spam-Status: No, score=-10.26 tagged_above=-999 required=5 tests=[AWL=0.339, 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 N-YMKSaemHlT; Thu, 18 Oct 2012 05:33:37 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6C9FF21F8455; Thu, 18 Oct 2012 05:33:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3504; q=dns/txt; s=iport; t=1350563617; x=1351773217; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Uiy8Pz0ZX8y3EUBS7qKswiOBNctKZTDxvDTSgUiO0Lo=; b=hlr5suAnnI0B4e32m9/4QAHZ9BZhUqiFwxV3WB16Bkq4Lc2vl2LZ25FX +OQt33eKAZRHYlwgvl1QPwBrdTNM+Ne23Iie5Sc0moXZj7c8zjWtarX8w piRp/8UQ8p/400r0aJRdjOw6Oy2pttuOTmzgKN2bXM/rCauizn26u+VyE Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIP2f1CtJXG//2dsb2JhbABFwD2BCIIgAQEBAwEBAQEPAVsLBQsCAQgRAwECKAcnCxQJCAIEDgUJEgeHXAYLnDGgK4tYhWJgA4gjjUiBFY00gWuCbw X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="132763717" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-1.cisco.com with ESMTP; 18 Oct 2012 12:33:37 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q9ICXaCS022349 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Oct 2012 12:33:36 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.200]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.001; Thu, 18 Oct 2012 07:33:36 -0500 From: "Bernie Volz (volz)" To: Ted Lemon Thread-Topic: [dhcwg] Volunteers to review draft-ietf-softwire-multicast-prefix-option-02.txt? Thread-Index: AQHNrSuN7cjYEIegMEC1weKrQzCzFZe+/z6w Date: Thu, 18 Oct 2012 12:33:35 +0000 Message-ID: <397855E6-E21A-4C51-A6FA-4B867B989A8E@cisco.com> References: <94C682931C08B048B7A8645303FDC9F36E64431C88@PUEXCB1B.nanterre.francetelecom.fr>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19284.002 x-tm-as-result: No--51.931900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "softwires-bounces@ietf.org" , " WG" Subject: Re: [dhcwg] Volunteers to review draft-ietf-softwire-multicast-prefix-option-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, 18 Oct 2012 12:33:38 -0000 Could we PLEASE not have yet another encoding format for prefixes. And why is a 12 octet field called ...64??? 12x8 =3D 96 last time I checked= my slide rule? The prefix should either be encoded as a full 128 bits (16 octets) OR using= the minimal encoding format (i.e., variable length with enough octets to h= andle the number of bits in the prefix - (prefix length + 7) / 8). I don't = really care which, but please do not add a third format. - Bernie Sent from my iPad On Oct 18, 2012, at 8:24 AM, "Ted Lemon" wrote: > This is a DHCPv6 option for carrying IPv4-Embedded multicast and unicast = IPv6 prefixes. The DHC working group should review this document for corr= ectness with respect to the DHCP option specification. Can I get a few vo= lunteers to give this a careful read to make sure the DHCP specification la= nguage is correct? >=20 > Begin forwarded message: >> From: >> Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-multicast-pr= efix-option-02.txt >> Date: October 18, 2012 1:37:48 AM EDT >>=20 >> We believe this version is ready for a WGLC. >>=20 >> Cheers, >> Med >>=20 >>=20 >>> -----Message d'origine----- >>> De : softwires-bounces@ietf.org=20 >>> [mailto:softwires-bounces@ietf.org] De la part de=20 >>> internet-drafts@ietf.org >>> Envoy=E9 : mardi 16 octobre 2012 17:03 >>> =C0 : i-d-announce@ietf.org >>> Cc : softwires@ietf.org >>> Objet : [Softwires] I-D Action:=20 >>> draft-ietf-softwire-multicast-prefix-option-02.txt >>>=20 >>>=20 >>> A New Internet-Draft is available from the on-line=20 >>> Internet-Drafts directories. >>> This draft is a work item of the Softwires Working Group of the IETF. >>>=20 >>> Title : DHCPv6 Option for IPv4-Embedded=20 >>> Multicast and Unicast IPv6 Prefixes >>> Author(s) : Mohamed Boucadair >>> Jacni Qin >>> Tina Tsou >>> Xiaohong Deng >>> Filename :=20 >>> draft-ietf-softwire-multicast-prefix-option-02.txt >>> Pages : 7 >>> Date : 2012-10-16 >>>=20 >>> Abstract: >>> This document defines Dynamic Host Configuration Protocol version 6 >>> (DHCPv6) Option for multicast transition solutions, aiming to convey >>> the IPv6 prefixes to be used to build unicast and multicast IPv4- >>> embedded IPv6 addresses. >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-softwire-multicast- >>> prefix-option >>>=20 >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-softwire-multicast-prefix >>> -option-02 >>>=20 >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-multicast- >>> prefix-option-02 >>>=20 >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >>>=20 >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From simon.perreault@viagenie.ca Thu Oct 18 06:13:02 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43CE921F873A for ; Thu, 18 Oct 2012 06:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-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 uSuO7aVegLq0 for ; Thu, 18 Oct 2012 06:13:01 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id ACC4521F872A for ; Thu, 18 Oct 2012 06:13:01 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:5c48:f469:9b94:d841]) by jazz.viagenie.ca (Postfix) with ESMTPSA id C856C415C4 for ; Thu, 18 Oct 2012 09:12:58 -0400 (EDT) Message-ID: <50800059.3030503@viagenie.ca> Date: Thu, 18 Oct 2012 09:12:57 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121009 Thunderbird/16.0 MIME-Version: 1.0 To: dhcwg@ietf.org References: <9D3C0AC1-D5B1-4C25-AC47-4D08E3252D54@nominum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-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, 18 Oct 2012 13:13:02 -0000 Le 2012-10-18 04:03, Wojciech Dec a écrit : > this option cannot be used to extend regular IPv4 clients or DHCP > servers to serve on plain IPv4-only networks Why not? From reading the draft, it looks to me like it can. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From volz@cisco.com Thu Oct 18 06:26:52 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C465921F878B for ; Thu, 18 Oct 2012 06:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.286 X-Spam-Level: X-Spam-Status: No, score=-10.286 tagged_above=-999 required=5 tests=[AWL=0.313, 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 8CsNJJePYGIX for ; Thu, 18 Oct 2012 06:26:51 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8826E21F8737 for ; Thu, 18 Oct 2012 06:26:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9598; q=dns/txt; s=iport; t=1350566811; x=1351776411; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=YeNaoCrlZQrU+nWlIqR8agvS2qDcIF2qqdzEELRtPr0=; b=CzYvBM68YxdQJ/niQxeYP8kJ1cwl+q4JG1Sj9jXoyItr5oL2aTYozZBl uHEBrqQSpLWYRxYoFA5IbT82UElGUp9UR4l/dK5omHNjegwoW33KSc2Fm kJ729+wGUxfRYATk0QCCfzVVVwod+o7XYLRNRnQkwbuFy96jXN1GmvlkB U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFgDgFCtJV2b/2dsb2JhbABFwDqBCIIgAQEBBAEBAQ8BWwsMBAIBCBEDAQEBAQodBycLFAkIAgQBDQUIARIHh2ILnDigN4tYhWJgA4gjjl2NNIFrgm+CFw X-IronPort-AV: E=Sophos;i="4.80,607,1344211200"; d="scan'208";a="133004837" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 18 Oct 2012 13:26:51 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q9IDQoa6024581 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Oct 2012 13:26:50 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.200]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.001; Thu, 18 Oct 2012 08:26:50 -0500 From: "Bernie Volz (volz)" To: "mohamed.boucadair@orange.com" , "dhcwg@ietf.org" Thread-Topic: OFFLIST RE: [dhcwg] Volunteers to review draft-ietf-softwire-multicast-prefix-option-02.txt? Thread-Index: AQHNrSuN7cjYEIegMEC1weKrQzCzFZe+/z6wgAACKRCAAAWOwA== Date: Thu, 18 Oct 2012 13:26:50 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E0F5401F9@xmb-rcd-x04.cisco.com> References: <94C682931C08B048B7A8645303FDC9F36E64431C88@PUEXCB1B.nanterre.francetelecom.fr>, <397855E6-E21A-4C51-A6FA-4B867B989A8E@cisco.com> <94C682931C08B048B7A8645303FDC9F36E64431EF9@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E64431EF9@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.252.133] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19284.002 x-tm-as-result: No--85.286300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ted Lemon Subject: Re: [dhcwg] OFFLIST RE: Volunteers to review draft-ietf-softwire-multicast-prefix-option-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, 18 Oct 2012 13:26:52 -0000 For the variable length encoding example see http://tools.ietf.org/html/dra= ft-ietf-mif-dhcpv6-route-option-05. We also used this in v4 for classless static route option (http://tools.iet= f.org/html/rfc3442). Regarding: * ASM_PREFIX64 and SSM_PREFIX64 are /96 This doesn't make sense. Why is 64 in the name when this is 96? Isn't that = very confusing? Why not drop the "64" from the name as these are obviously = variable length prefixes (given that they have prefix length). Perhaps thes= e are a softwire standard name, but it seems to be a badly chosen one to me= . Regarding the encoding/diagram, you should use: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_PREFIX64 | option-length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | asm-length | | +-+-+-+-+-+-+-+-+ : : ASM_PREFIX (VARIABLE octets) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ssm-length | | +-+-+-+-+-+-+-+-+ : : SSM_PREFIX (VARIABLE octets) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | unicast-length| | +-+-+-+-+-+-+-+-+ : : U_PREFIX (VARIABLE octets) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The *-length field determine how long each field is - it is = +7/8 octets (i.e., it specifies the maximum number of octets required to ho= ld the prefix). Note that the option-length is 3 + ((asm-length+7)/8) + ((s= sm-length+7)/8) + ((unicast-length+7)/8). I'd also clean up the asm-length (and other length) description to somethin= g like: asm-length: the prefix-length for the ASM IPv4-embedded prefix, as an 8-bit unsigned integer (0 to 128). This field represents the number of valid leading bits in the prefix. ASM_PREFIX: this field identifies the IPv6 multicast prefix to be used to synthesize the IPv4-embedded IPv6 addresses of the multicast groups. It is a variable size field with the length of the field defined by the asm-length field and is rounded up to the nearest octet boundary (if case when asm-length is not divisible by 8). In such case any additional padding bits must be zeroed. (And similar changes for the others.) Or, if you don't want the complexity of variable length fields, please use = 16 octet fields for the prefix, not 12 octet. The reason for this is that t= his is yet another encoding format that servers, clients, and packet decode= rs would need to be support and just makes adoption of the option much more= difficult as implementations need to support this new encoding format (unl= ess of course you want people to enter the 'binary' (hex) values for the op= tion data - which is likely not a good idea). - Bernie -----Original Message----- From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com]=20 Sent: Thursday, October 18, 2012 8:50 AM To: Bernie Volz (volz) Cc: Ted Lemon Subject: OFFLIST RE: [dhcwg] Volunteers to review draft-ietf-softwire-multi= cast-prefix-option-02.txt? Importance: High Dear Bernie, As I'm not sure I understand your comment, I prefer to send you this messag= e offline. I will send an answer to the list latter. Below some clarification for the length of these prefixes: * ASM_PREFIX64 and SSM_PREFIX64 are /96 * U_PREFIX64 is a prefix with variable length; the maximum length is /96 Could you please let me know what is wrong with this text: asm-length: the length for the ASM IPv4-emebdded IPv6 prefix in bits. If the field is set to 0, all bits of ASM_PREFIX64 field MUST be set to zeros. ASM_PREFIX64: this field identifies the IPv6 multicast prefix to be used to synthesize the IPv4-embedded IPv6 addresses of the multicast groups. The conveyed multicast IPv6 prefix MUST belong to the ASM range. ssm-length: the length for the SSM IPv4-emebdded IPv6 prefix in bits. If the field is set to 0, all bits of SSM_PREFIX64 field MUST be set to zeros. SSM_PREFIX64: this field identifies the IPv6 multicast prefix to be used to synthesize the IPv4-embedded IPv6 addresses of the multicast groups. The conveyed multicast IPv6 prefix MUST belong to the SSM range. unicast-length: the length for the unicast IPv4-emebdded IPv6 prefix in bits. If the field is set to 0, all bits of U_PREFIX64 field MUST be set to zeros. U_PREFIX64: this field identifies the IPv6 unicast prefix to be used in SSM mode for constructing the IPv4-embedded IPv6 addresses of the multicast sources. It may also be used to extract the IPv4 address from the received multicast data flows. The address mapping MUST follow the guidelines documented in [RFC6052]. Or you are referring to the figure? Thanks. Cheers, Med >-----Message d'origine----- >De : dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] De la part=20 >de Bernie Volz (volz) Envoy=E9 : jeudi 18 octobre 2012 14:34 =C0 : Ted=20 >Lemon Cc : softwires-bounces@ietf.org; WG Objet : Re:=20 >[dhcwg] Volunteers to review=20 >draft-ietf-softwire-multicast-prefix-option-02.txt? > >Could we PLEASE not have yet another encoding format for prefixes. > >And why is a 12 octet field called ...64??? 12x8 =3D 96 last time I=20 >checked my slide rule? > >The prefix should either be encoded as a full 128 bits (16 >octets) OR using the minimal encoding format (i.e., variable length=20 >with enough octets to handle the number of bits in the prefix - (prefix=20 >length + 7) / 8). I don't really care which, but please do not add a=20 >third format. > >- Bernie > >Sent from my iPad > >On Oct 18, 2012, at 8:24 AM, "Ted Lemon" wrote: > >> This is a DHCPv6 option for carrying IPv4-Embedded multicast >and unicast IPv6 prefixes. The DHC working group should=20 >review this document for correctness with respect to the DHCP=20 >option specification. Can I get a few volunteers to give=20 >this a careful read to make sure the DHCP specification language is=20 >correct? >>=20 >> Begin forwarded message: >>> From: >>> Subject: Re: [Softwires] I-D Action: =20 >draft-ietf-softwire-multicast-prefix-option-02.txt >>> Date: October 18, 2012 1:37:48 AM EDT >>>=20 >>> We believe this version is ready for a WGLC. >>>=20 >>> Cheers, >>> Med >>>=20 >>>=20 >>>> -----Message d'origine----- >>>> De : softwires-bounces@ietf.org >>>> [mailto:softwires-bounces@ietf.org] De la part de=20 >>>> internet-drafts@ietf.org Envoy=E9 : mardi 16 octobre 2012 17:03 =C0 := =20 >>>> i-d-announce@ietf.org Cc : softwires@ietf.org Objet : [Softwires]=20 >>>> I-D Action: >>>> draft-ietf-softwire-multicast-prefix-option-02.txt >>>>=20 >>>>=20 >>>> A New Internet-Draft is available from the on-line Internet-Drafts=20 >>>> directories. >>>> This draft is a work item of the Softwires Working Group >of the IETF. >>>>=20 >>>> Title : DHCPv6 Option for IPv4-Embedded=20 >>>> Multicast and Unicast IPv6 Prefixes >>>> Author(s) : Mohamed Boucadair >>>> Jacni Qin >>>> Tina Tsou >>>> Xiaohong Deng >>>> Filename :=20 >>>> draft-ietf-softwire-multicast-prefix-option-02.txt >>>> Pages : 7 >>>> Date : 2012-10-16 >>>>=20 >>>> Abstract: >>>> This document defines Dynamic Host Configuration Protocol version 6 >>>> (DHCPv6) Option for multicast transition solutions, aiming >to convey >>>> the IPv6 prefixes to be used to build unicast and multicast IPv4-=20 >>>> embedded IPv6 addresses. >>>>=20 >>>>=20 >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-softwire-multicast- >>>> prefix-option >>>>=20 >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-ietf-softwire-multicast-prefix >>>> -option-02 >>>>=20 >>>> A diff from the previous version is available at: >>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-multicast- >>>> prefix-option-02 >>>>=20 >>>>=20 >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>>=20 >>>> _______________________________________________ >>>> Softwires mailing list >>>> Softwires@ietf.org >>>> https://www.ietf.org/mailman/listinfo/softwires >>>>=20 >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >>=20 >> _______________________________________________ >> 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 otroan@employees.org Thu Oct 18 06:28:14 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E26F521F85B6 for ; Thu, 18 Oct 2012 06:28:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.247 X-Spam-Level: X-Spam-Status: No, score=-10.247 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 6Uy12ZNx5tQ0 for ; Thu, 18 Oct 2012 06:28:14 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 9DCC921F85A1 for ; Thu, 18 Oct 2012 06:28:13 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At0KAMICgFCQ/khL/2dsb2JhbABFvzABAwEDgQKBCIIgAQEBAwESAQpcEAtGVwY1h1wGnEGgN5E6YAOkNIFrgnE X-IronPort-AV: E=Sophos;i="4.80,607,1344211200"; d="scan'208";a="8916731" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-4.cisco.com with ESMTP; 18 Oct 2012 13:28:12 +0000 Received: from dhcp-lys01-vla250-10-147-112-212.cisco.com (dhcp-lys01-vla250-10-147-112-212.cisco.com [10.147.112.212]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9IDSCoB013855 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 18 Oct 2012 13:28:12 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <50800059.3030503@viagenie.ca> Date: Thu, 18 Oct 2012 15:28:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4E18E4F4-7E60-41F7-8700-83EF2CF1D4A4@employees.org> References: <9D3C0AC1-D5B1-4C25-AC47-4D08E3252D54@nominum.com> <50800059.3030503@viagenie.ca> To: Simon Perreault X-Mailer: Apple Mail (2.1498) Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-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, 18 Oct 2012 13:28:15 -0000 Simon, >> this option cannot be used to extend regular IPv4 clients or DHCP >> servers to serve on plain IPv4-only networks >=20 > Why not? =46rom reading the draft, it looks to me like it can. the option is there to give a shared IPv4 address to the DHCP client. example; two hosts on a the network. one gets IPv4 address 1.1.1.1 port = range 1001-4000, the other IPv4 address 1.1.1.1 port range 4001-8000. without a "larger context" (i.e. some sort of encapsulation, how is that = supposed to work? think ARP. cheers, Ole From Ted.Lemon@nominum.com Thu Oct 18 06:34:28 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA7521F8701 for ; Thu, 18 Oct 2012 06:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.336 X-Spam-Level: X-Spam-Status: No, score=-106.336 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 o1SrDiwaa-Jk for ; Thu, 18 Oct 2012 06:34:27 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id 9F66421F86AB for ; Thu, 18 Oct 2012 06:34:27 -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 DSNKUIAFY3I5xH+9ue4a9jO76M8a1KlJa0x4@postini.com; Thu, 18 Oct 2012 06:34:27 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 CBD7E1B8327 for ; Thu, 18 Oct 2012 06:34:26 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id C082C19005C; Thu, 18 Oct 2012 06:34:26 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Thu, 18 Oct 2012 06:34:26 -0700 From: Ted Lemon To: =?iso-8859-1?Q?Ole_Tr=F8an?= Thread-Topic: [dhcwg] Call for adoption: draft-sun-dhc-port-set-option Thread-Index: AQHNput68Hhly3n5akOtNZsf4t9jOpe/NbeAgABWX4CAAARBgIAAAb6A Date: Thu, 18 Oct 2012 13:34:26 +0000 Message-ID: <219448E3-6A90-411D-A430-EDE011E5E75E@nominum.com> References: <9D3C0AC1-D5B1-4C25-AC47-4D08E3252D54@nominum.com> <50800059.3030503@viagenie.ca> <4E18E4F4-7E60-41F7-8700-83EF2CF1D4A4@employees.org> In-Reply-To: <4E18E4F4-7E60-41F7-8700-83EF2CF1D4A4@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <9C6C88FB192B1E4E8BEF114423C6555E@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-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, 18 Oct 2012 13:34:28 -0000 On Oct 18, 2012, at 9:28 AM, Ole Tr=F8an wrote: > without a "larger context" (i.e. some sort of encapsulation, how is that = supposed to work? think ARP. Just to be clear here, the DHC working group is not proposing to work on de= fining a way to share IP addresses. The DHC working group is proposing to= work on a way to convey a port range to a device which shares IP addresses= , using DHCP. Anything more than that would definitely be out of scope fo= r DHC. BTW, we discussed using port ranges versus using masks; the reason for usin= g masks is that it's easier to do on the fast path than ranges. From otroan@employees.org Thu Oct 18 06:38:57 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B096321F849C for ; Thu, 18 Oct 2012 06:38:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.251 X-Spam-Level: X-Spam-Status: No, score=-10.251 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 LgToaLAqmg5Y for ; Thu, 18 Oct 2012 06:38:57 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id E7B7021F84B8 for ; Thu, 18 Oct 2012 06:38:56 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak8JAK4FgFCQ/khR/2dsb2JhbABFvzAEBIECgQiCIAEBAQMBEgEKXBALRlcGNYdcBpxCoDeROmADpDSBa4Jx X-IronPort-AV: E=Sophos;i="4.80,607,1344211200"; d="scan'208";a="8907032" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-3.cisco.com with ESMTP; 18 Oct 2012 13:38:53 +0000 Received: from dhcp-lys01-vla250-10-147-112-212.cisco.com (dhcp-lys01-vla250-10-147-112-212.cisco.com [10.147.112.212]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9IDcqXJ008730 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 18 Oct 2012 13:38:53 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <219448E3-6A90-411D-A430-EDE011E5E75E@nominum.com> Date: Thu, 18 Oct 2012 15:38:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <50F411F4-D3C5-4CED-B9BD-5E552C61C5EE@employees.org> References: <9D3C0AC1-D5B1-4C25-AC47-4D08E3252D54@nominum.com> <50800059.3030503@viagenie.ca> <4E18E4F4-7E60-41F7-8700-83EF2CF1D4A4@employees.org> <219448E3-6A90-411D-A430-EDE011E5E75E@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1498) Cc: "" Subject: Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-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, 18 Oct 2012 13:38:57 -0000 >> without a "larger context" (i.e. some sort of encapsulation, how is = that supposed to work? think ARP. >=20 > Just to be clear here, the DHC working group is not proposing to work = on defining a way to share IP addresses. The DHC working group is = proposing to work on a way to convey a port range to a device which = shares IP addresses, using DHCP. Anything more than that would = definitely be out of scope for DHC. >=20 > BTW, we discussed using port ranges versus using masks; the reason for = using masks is that it's easier to do on the fast path than ranges. right. draft-ietf-softwire-map uses a mask. you propose support for a = discontiguous mask, our proposal a contiguous one. anyhow, let us move = this to softwire. cheers, Ole= From mohamed.boucadair@orange.com Thu Oct 18 06:42:29 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B550C21F84E2 for ; Thu, 18 Oct 2012 06:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.13 X-Spam-Level: X-Spam-Status: No, score=-2.13 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=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 lB0qQpIK84Ci for ; Thu, 18 Oct 2012 06:42:28 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 2278F21F849C for ; Thu, 18 Oct 2012 06:42:28 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 89DEC18C11D; Thu, 18 Oct 2012 15:42:27 +0200 (CEST) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 6CB414C015; Thu, 18 Oct 2012 15:42:27 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Thu, 18 Oct 2012 15:42:27 +0200 From: To: "Bernie Volz (volz)" , "dhcwg@ietf.org" Date: Thu, 18 Oct 2012 15:42:25 +0200 Thread-Topic: [dhcwg] Volunteers to review draft-ietf-softwire-multicast-prefix-option-02.txt? Thread-Index: AQHNrSuN7cjYEIegMEC1weKrQzCzFZe+/z6wgAACKRCAAAWOwIAAB/3Q Message-ID: <94C682931C08B048B7A8645303FDC9F36E64431F71@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E64431C88@PUEXCB1B.nanterre.francetelecom.fr>, <397855E6-E21A-4C51-A6FA-4B867B989A8E@cisco.com> <94C682931C08B048B7A8645303FDC9F36E64431EF9@PUEXCB1B.nanterre.francetelecom.fr> <489D13FBFA9B3E41812EA89F188F018E0F5401F9@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E0F5401F9@xmb-rcd-x04.cisco.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.19.115414 Cc: Ted Lemon Subject: Re: [dhcwg] Volunteers to review draft-ietf-softwire-multicast-prefix-option-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, 18 Oct 2012 13:42:29 -0000 Re-, Please see inline.=20 Cheers, Med=20 >-----Message d'origine----- >De : Bernie Volz (volz) [mailto:volz@cisco.com]=20 >Envoy=E9 : jeudi 18 octobre 2012 15:27 >=C0 : BOUCADAIR Mohamed OLNC/OLN; dhcwg@ietf.org >Cc : Ted Lemon >Objet : RE: OFFLIST RE: [dhcwg] Volunteers to review=20 >draft-ietf-softwire-multicast-prefix-option-02.txt? > >For the variable length encoding example see=20 >http://tools.ietf.org/html/draft-ietf-mif-dhcpv6-route-option-05. > >We also used this in v4 for classless static route option=20 >(http://tools.ietf.org/html/rfc3442). Med: Thanks for the pointers. I'm aware of these documents.=20 > >Regarding: > >* ASM_PREFIX64 and SSM_PREFIX64 are /96 > >This doesn't make sense. Med: What does not make sense? These are specific prefixes which are provis= ioned to build a multicast IPv6 address embedding an IPv4 address in the la= st 32 bits. The recommended length for these prefixes is /96.=20 Why is 64 in the name when this is=20 >96? Isn't that very confusing?=20 Med: 64 is there because these prefixes are used for IPv4-IPv6 multicast in= terconnection.=20 Why not drop the "64" from the=20 >name as these are obviously variable length prefixes (given=20 >that they have prefix length). Perhaps these are a softwire=20 >standard name, but it seems to be a badly chosen one to me. Med: PREFIX64 is widely used in IPv4/IPv6 interconnection matters.=20 > >Regarding the encoding/diagram, you should use: > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | OPTION_PREFIX64 | option-length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | asm-length | | > +-+-+-+-+-+-+-+-+ : > : ASM_PREFIX (VARIABLE octets) =20 > : > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ssm-length | | > +-+-+-+-+-+-+-+-+ : > : SSM_PREFIX (VARIABLE octets) =20 > : > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | unicast-length| | > +-+-+-+-+-+-+-+-+ : > : U_PREFIX (VARIABLE octets) =20 > : > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >The *-length field determine how long each field is - it is=20 >+7/8 octets (i.e., it specifies the maximum=20 >number of octets required to hold the prefix). Note that the=20 >option-length is 3 + ((asm-length+7)/8) + ((ssm-length+7)/8) +=20 >((unicast-length+7)/8). > >I'd also clean up the asm-length (and other length)=20 >description to something like: > > asm-length: the prefix-length for the ASM IPv4-embedded prefix, as > an 8-bit unsigned integer (0 to 128). This field=20 >represents the > number of valid leading bits in the prefix. > ASM_PREFIX: this field identifies the IPv6 multicast prefix to be > used to synthesize the IPv4-embedded IPv6 addresses of the > multicast groups. It is a variable size field with the length of > the field defined by the asm-length field and is rounded up to > the nearest octet boundary (if case when asm-length is not > divisible by 8). In such case any additional padding bits must > be zeroed. > >(And similar changes for the others.) > >Or, if you don't want the complexity of variable length=20 >fields, please use 16 octet fields for the prefix, not 12=20 >octet. The reason for this is that this is yet another=20 >encoding format that servers, clients, and packet decoders=20 >would need to be support and just makes adoption of the option=20 >much more difficult as implementations need to support this=20 >new encoding format (unless of course you want people to enter=20 >the 'binary' (hex) values for the option data - which is=20 >likely not a good idea). > >- Bernie > >-----Original Message----- >From: mohamed.boucadair@orange.com=20 >[mailto:mohamed.boucadair@orange.com]=20 >Sent: Thursday, October 18, 2012 8:50 AM >To: Bernie Volz (volz) >Cc: Ted Lemon >Subject: OFFLIST RE: [dhcwg] Volunteers to review=20 >draft-ietf-softwire-multicast-prefix-option-02.txt? >Importance: High > >Dear Bernie, > >As I'm not sure I understand your comment, I prefer to send=20 >you this message offline. I will send an answer to the list latter. > >Below some clarification for the length of these prefixes: > >* ASM_PREFIX64 and SSM_PREFIX64 are /96 >* U_PREFIX64 is a prefix with variable length; the maximum=20 >length is /96 > >Could you please let me know what is wrong with this text: > > asm-length: the length for the ASM IPv4-emebdded IPv6 prefix in > bits. If the field is set to 0, all bits of ASM_PREFIX64 field > MUST be set to zeros. > ASM_PREFIX64: this field identifies the IPv6 multicast prefix to be > used to synthesize the IPv4-embedded IPv6 addresses of the > multicast groups. The conveyed multicast IPv6 prefix MUST belong > to the ASM range. > ssm-length: the length for the SSM IPv4-emebdded IPv6 prefix in > bits. If the field is set to 0, all bits of SSM_PREFIX64 field > MUST be set to zeros. > SSM_PREFIX64: this field identifies the IPv6 multicast prefix to be > used to synthesize the IPv4-embedded IPv6 addresses of the > multicast groups. The conveyed multicast IPv6 prefix MUST belong > to the SSM range. > unicast-length: the length for the unicast IPv4-emebdded=20 >IPv6 prefix > in bits. If the field is set to 0, all bits of U_PREFIX64 field > MUST be set to zeros. > U_PREFIX64: this field identifies the IPv6 unicast prefix=20 >to be used > in SSM mode for constructing the IPv4-embedded IPv6 addresses of > the multicast sources. It may also be used to extract the IPv4 > address from the received multicast data flows. The address > mapping MUST follow the guidelines documented in [RFC6052]. > > >Or you are referring to the figure? > >Thanks. > >Cheers, >Med > > >>-----Message d'origine----- >>De : dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 >De la part=20 >>de Bernie Volz (volz) Envoy=E9 : jeudi 18 octobre 2012 14:34 =C0 : Ted=20 >>Lemon Cc : softwires-bounces@ietf.org; WG=20 >Objet : Re:=20 >>[dhcwg] Volunteers to review=20 >>draft-ietf-softwire-multicast-prefix-option-02.txt? >> >>Could we PLEASE not have yet another encoding format for prefixes. >> >>And why is a 12 octet field called ...64??? 12x8 =3D 96 last time I=20 >>checked my slide rule? >> >>The prefix should either be encoded as a full 128 bits (16 >>octets) OR using the minimal encoding format (i.e., variable length=20 >>with enough octets to handle the number of bits in the prefix=20 >- (prefix=20 >>length + 7) / 8). I don't really care which, but please do not add a=20 >>third format. >> >>- Bernie >> >>Sent from my iPad >> >>On Oct 18, 2012, at 8:24 AM, "Ted Lemon"=20 > wrote: >> >>> This is a DHCPv6 option for carrying IPv4-Embedded multicast >>and unicast IPv6 prefixes. The DHC working group should=20 >>review this document for correctness with respect to the DHCP=20 >>option specification. Can I get a few volunteers to give=20 >>this a careful read to make sure the DHCP specification language is=20 >>correct? >>>=20 >>> Begin forwarded message: >>>> From: >>>> Subject: Re: [Softwires] I-D Action: =20 >>draft-ietf-softwire-multicast-prefix-option-02.txt >>>> Date: October 18, 2012 1:37:48 AM EDT >>>>=20 >>>> We believe this version is ready for a WGLC. >>>>=20 >>>> Cheers, >>>> Med >>>>=20 >>>>=20 >>>>> -----Message d'origine----- >>>>> De : softwires-bounces@ietf.org >>>>> [mailto:softwires-bounces@ietf.org] De la part de=20 >>>>> internet-drafts@ietf.org Envoy=E9 : mardi 16 octobre 2012 17:03 =C0 := =20 >>>>> i-d-announce@ietf.org Cc : softwires@ietf.org Objet : [Softwires]=20 >>>>> I-D Action: >>>>> draft-ietf-softwire-multicast-prefix-option-02.txt >>>>>=20 >>>>>=20 >>>>> A New Internet-Draft is available from the on-line=20 >Internet-Drafts=20 >>>>> directories. >>>>> This draft is a work item of the Softwires Working Group >>of the IETF. >>>>>=20 >>>>> Title : DHCPv6 Option for IPv4-Embedded=20 >>>>> Multicast and Unicast IPv6 Prefixes >>>>> Author(s) : Mohamed Boucadair >>>>> Jacni Qin >>>>> Tina Tsou >>>>> Xiaohong Deng >>>>> Filename :=20 >>>>> draft-ietf-softwire-multicast-prefix-option-02.txt >>>>> Pages : 7 >>>>> Date : 2012-10-16 >>>>>=20 >>>>> Abstract: >>>>> This document defines Dynamic Host Configuration Protocol=20 >version 6 >>>>> (DHCPv6) Option for multicast transition solutions, aiming >>to convey >>>>> the IPv6 prefixes to be used to build unicast and multicast IPv4-=20 >>>>> embedded IPv6 addresses. >>>>>=20 >>>>>=20 >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-softwire-multicast- >>>>> prefix-option >>>>>=20 >>>>> There's also a htmlized version available at: >>>>> http://tools.ietf.org/html/draft-ietf-softwire-multicast-prefix >>>>> -option-02 >>>>>=20 >>>>> A diff from the previous version is available at: >>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-multicast- >>>>> prefix-option-02 >>>>>=20 >>>>>=20 >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>=20 >>>>> _______________________________________________ >>>>> Softwires mailing list >>>>> Softwires@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/softwires >>>>>=20 >>>> _______________________________________________ >>>> Softwires mailing list >>>> Softwires@ietf.org >>>> https://www.ietf.org/mailman/listinfo/softwires >>>=20 >>> _______________________________________________ >>> 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 volz@cisco.com Thu Oct 18 06:51:36 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A753E21F8812 for ; Thu, 18 Oct 2012 06:51:36 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up entirely of whitespace (char 20 hex): References: ...64431EF9@PUEXCB1B.nanterre.francetelecom.fr>\n X-Spam-Flag: NO X-Spam-Score: -10.308 X-Spam-Level: X-Spam-Status: No, score=-10.308 tagged_above=-999 required=5 tests=[AWL=0.291, 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 qDVS10AH0kBH for ; Thu, 18 Oct 2012 06:51:35 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 2974021F87B0 for ; Thu, 18 Oct 2012 06:51:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10878; q=dns/txt; s=iport; t=1350568295; x=1351777895; h=from:to:cc:subject:date:message-id:references: content-transfer-encoding:mime-version; bh=4Qlm8aO7Zvt0bKF2YxUz3h4KCJkXFn84P0Z6kQFj2a8=; b=SEBs+KvXdVtxKtcqLbBAQpdojnsHz4KkvUmTDT87KsGBN3W4eY5kDAEk a0Hz/rgkWXREIw29nvipZkQe5b+AUS+NAbhEr4bUouCtz7VlPNQ83C2fy yndUN6YKVKrMufs3zYkkJFvBP84vdQib8bqT4gV35IJAO+gFHw1eLd4fF c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHoIgFCtJXHB/2dsb2JhbABFwDqBCIIgAQEBBAEBAQ8BWwsMBAIBCBEDAQEBAQodBycLFAkIAgQBDQUIARIHh2ILnDWgOItYhWJgA4gjjl2NNIFrgm+CFw X-IronPort-AV: E=Sophos;i="4.80,607,1344211200"; d="scan'208";a="132993141" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-2.cisco.com with ESMTP; 18 Oct 2012 13:51:34 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q9IDpY9j004551 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Oct 2012 13:51:34 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.200]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.001; Thu, 18 Oct 2012 08:51:34 -0500 From: "Bernie Volz (volz)" To: "mohamed.boucadair@orange.com" , "dhcwg@ietf.org" , "Tomek Mrugalski (tomasz.mrugalski@gmail.com)" Thread-Topic: OFFLIST RE: [dhcwg] Volunteers to review draft-ietf-softwire-multicast-prefix-option-02.txt? Thread-Index: AQHNrSuN7cjYEIegMEC1weKrQzCzFZe+/z6wgAACKRCAAAWOwIAACsuA Date: Thu, 18 Oct 2012 13:51:33 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E0F540374@xmb-rcd-x04.cisco.com> References: <94C682931C08B048B7A8645303FDC9F36E64431C88@PUEXCB1B.nanterre.francetelecom.fr>, <397855E6-E21A-4C51-A6FA-4B867B989A8E@cisco.com> <94C682931C08B048B7A8645303FDC9F36E64431EF9@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.252.133] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19284.002 x-tm-as-result: No--82.695700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ted Lemon Subject: Re: [dhcwg] OFFLIST RE: Volunteers to review draft-ietf-softwire-multicast-prefix-option-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, 18 Oct 2012 13:51:36 -0000 Perhaps we should consider updating draft-ietf-dhc-option-guidelines to inc= lude a section on IPv6 prefixes? 5.x Option with IPv6 prefixes There are two formats that should be used for IPv6 prefixes. One format is a 8-bit prefix length field followed by a fixed 16-octet (128-bit) prefix. An example of this encoding is the IAPREFIX option (see RFC 3633). The other format is a 8-bit prefix length field followed by a variable length, 0 to 16, octet field contain the required prefix bits. The length is rounded up to the nearest octet boundary (if case when prefix length is not divisible by 8). In such case any additional padding bits must be zeroed. [Not sure if we have an RFC yet that shows an example of this encoding.] While the first format is simpler to use, the second format is (now) slightly more preferred as it reduces the option and packet size. Note that comment about preference might be something to be debated. - Bernie -----Original Message----- From: Bernie Volz (volz)=20 Sent: Thursday, October 18, 2012 9:27 AM To: 'mohamed.boucadair@orange.com'; dhcwg@ietf.org Cc: Ted Lemon Subject: RE: OFFLIST RE: [dhcwg] Volunteers to review draft-ietf-softwire-m= ulticast-prefix-option-02.txt? For the variable length encoding example see http://tools.ietf.org/html/dra= ft-ietf-mif-dhcpv6-route-option-05. We also used this in v4 for classless static route option (http://tools.iet= f.org/html/rfc3442). Regarding: * ASM_PREFIX64 and SSM_PREFIX64 are /96 This doesn't make sense. Why is 64 in the name when this is 96? Isn't that = very confusing? Why not drop the "64" from the name as these are obviously = variable length prefixes (given that they have prefix length). Perhaps thes= e are a softwire standard name, but it seems to be a badly chosen one to me= . Regarding the encoding/diagram, you should use: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_PREFIX64 | option-length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | asm-length | | +-+-+-+-+-+-+-+-+ : : ASM_PREFIX (VARIABLE octets) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ssm-length | | +-+-+-+-+-+-+-+-+ : : SSM_PREFIX (VARIABLE octets) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | unicast-length| | +-+-+-+-+-+-+-+-+ : : U_PREFIX (VARIABLE octets) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The *-length field determine how long each field is - it is = +7/8 octets (i.e., it specifies the maximum number of octets required to ho= ld the prefix). Note that the option-length is 3 + ((asm-length+7)/8) + ((s= sm-length+7)/8) + ((unicast-length+7)/8). I'd also clean up the asm-length (and other length) description to somethin= g like: asm-length: the prefix-length for the ASM IPv4-embedded prefix, as an 8-bit unsigned integer (0 to 128). This field represents the number of valid leading bits in the prefix. ASM_PREFIX: this field identifies the IPv6 multicast prefix to be used to synthesize the IPv4-embedded IPv6 addresses of the multicast groups. It is a variable size field with the length of the field defined by the asm-length field and is rounded up to the nearest octet boundary (if case when asm-length is not divisible by 8). In such case any additional padding bits must be zeroed. (And similar changes for the others.) Or, if you don't want the complexity of variable length fields, please use = 16 octet fields for the prefix, not 12 octet. The reason for this is that t= his is yet another encoding format that servers, clients, and packet decode= rs would need to be support and just makes adoption of the option much more= difficult as implementations need to support this new encoding format (unl= ess of course you want people to enter the 'binary' (hex) values for the op= tion data - which is likely not a good idea). - Bernie -----Original Message----- From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] Sent: Thursday, October 18, 2012 8:50 AM To: Bernie Volz (volz) Cc: Ted Lemon Subject: OFFLIST RE: [dhcwg] Volunteers to review draft-ietf-softwire-multi= cast-prefix-option-02.txt? Importance: High Dear Bernie, As I'm not sure I understand your comment, I prefer to send you this messag= e offline. I will send an answer to the list latter. Below some clarification for the length of these prefixes: * ASM_PREFIX64 and SSM_PREFIX64 are /96 * U_PREFIX64 is a prefix with variable length; the maximum length is /96 Could you please let me know what is wrong with this text: asm-length: the length for the ASM IPv4-emebdded IPv6 prefix in bits. If the field is set to 0, all bits of ASM_PREFIX64 field MUST be set to zeros. ASM_PREFIX64: this field identifies the IPv6 multicast prefix to be used to synthesize the IPv4-embedded IPv6 addresses of the multicast groups. The conveyed multicast IPv6 prefix MUST belong to the ASM range. ssm-length: the length for the SSM IPv4-emebdded IPv6 prefix in bits. If the field is set to 0, all bits of SSM_PREFIX64 field MUST be set to zeros. SSM_PREFIX64: this field identifies the IPv6 multicast prefix to be used to synthesize the IPv4-embedded IPv6 addresses of the multicast groups. The conveyed multicast IPv6 prefix MUST belong to the SSM range. unicast-length: the length for the unicast IPv4-emebdded IPv6 prefix in bits. If the field is set to 0, all bits of U_PREFIX64 field MUST be set to zeros. U_PREFIX64: this field identifies the IPv6 unicast prefix to be used in SSM mode for constructing the IPv4-embedded IPv6 addresses of the multicast sources. It may also be used to extract the IPv4 address from the received multicast data flows. The address mapping MUST follow the guidelines documented in [RFC6052]. Or you are referring to the figure? Thanks. Cheers, Med >-----Message d'origine----- >De : dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] De la part=20 >de Bernie Volz (volz) Envoy=E9 : jeudi 18 octobre 2012 14:34 =C0 : Ted=20 >Lemon Cc : softwires-bounces@ietf.org; WG Objet : Re: >[dhcwg] Volunteers to review >draft-ietf-softwire-multicast-prefix-option-02.txt? > >Could we PLEASE not have yet another encoding format for prefixes. > >And why is a 12 octet field called ...64??? 12x8 =3D 96 last time I=20 >checked my slide rule? > >The prefix should either be encoded as a full 128 bits (16 >octets) OR using the minimal encoding format (i.e., variable length=20 >with enough octets to handle the number of bits in the prefix - (prefix=20 >length + 7) / 8). I don't really care which, but please do not add a=20 >third format. > >- Bernie > >Sent from my iPad > >On Oct 18, 2012, at 8:24 AM, "Ted Lemon" wrote: > >> This is a DHCPv6 option for carrying IPv4-Embedded multicast >and unicast IPv6 prefixes. The DHC working group should=20 >review this document for correctness with respect to the DHCP=20 >option specification. Can I get a few volunteers to give=20 >this a careful read to make sure the DHCP specification language is=20 >correct? >>=20 >> Begin forwarded message: >>> From: >>> Subject: Re: [Softwires] I-D Action: =20 >draft-ietf-softwire-multicast-prefix-option-02.txt >>> Date: October 18, 2012 1:37:48 AM EDT >>>=20 >>> We believe this version is ready for a WGLC. >>>=20 >>> Cheers, >>> Med >>>=20 >>>=20 >>>> -----Message d'origine----- >>>> De : softwires-bounces@ietf.org >>>> [mailto:softwires-bounces@ietf.org] De la part de=20 >>>> internet-drafts@ietf.org Envoy=E9 : mardi 16 octobre 2012 17:03 =C0 : >>>> i-d-announce@ietf.org Cc : softwires@ietf.org Objet : [Softwires]=20 >>>> I-D Action: >>>> draft-ietf-softwire-multicast-prefix-option-02.txt >>>>=20 >>>>=20 >>>> A New Internet-Draft is available from the on-line Internet-Drafts=20 >>>> directories. >>>> This draft is a work item of the Softwires Working Group >of the IETF. >>>>=20 >>>> Title : DHCPv6 Option for IPv4-Embedded=20 >>>> Multicast and Unicast IPv6 Prefixes >>>> Author(s) : Mohamed Boucadair >>>> Jacni Qin >>>> Tina Tsou >>>> Xiaohong Deng >>>> Filename :=20 >>>> draft-ietf-softwire-multicast-prefix-option-02.txt >>>> Pages : 7 >>>> Date : 2012-10-16 >>>>=20 >>>> Abstract: >>>> This document defines Dynamic Host Configuration Protocol version 6 >>>> (DHCPv6) Option for multicast transition solutions, aiming >to convey >>>> the IPv6 prefixes to be used to build unicast and multicast IPv4-=20 >>>> embedded IPv6 addresses. >>>>=20 >>>>=20 >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-softwire-multicast- >>>> prefix-option >>>>=20 >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-ietf-softwire-multicast-prefix >>>> -option-02 >>>>=20 >>>> A diff from the previous version is available at: >>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-multicast- >>>> prefix-option-02 >>>>=20 >>>>=20 >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>>=20 >>>> _______________________________________________ >>>> Softwires mailing list >>>> Softwires@ietf.org >>>> https://www.ietf.org/mailman/listinfo/softwires >>>>=20 >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >>=20 >> _______________________________________________ >> 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 otroan@employees.org Thu Oct 18 07:00:48 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A089E21F8808 for ; Thu, 18 Oct 2012 07:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.255 X-Spam-Level: X-Spam-Status: No, score=-10.255 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 RYbUiw2bQI4m for ; Thu, 18 Oct 2012 07:00:48 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id E24F021F8732 for ; Thu, 18 Oct 2012 07:00:47 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAGcKgFCQ/khN/2dsb2JhbABFwDqBCIIgAQEBAwEBAQEPAQodNAsFCwtGJzAGEyKHXAYLnDOgNASROmADpDSBa4Jx X-IronPort-AV: E=Sophos;i="4.80,607,1344211200"; d="scan'208";a="145472960" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 18 Oct 2012 14:00:45 +0000 Received: from dhcp-lys01-vla250-10-147-112-212.cisco.com (dhcp-lys01-vla250-10-147-112-212.cisco.com [10.147.112.212]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q9IE0iBd032164 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 18 Oct 2012 14:00:45 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Thu, 18 Oct 2012 16:00:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9D3C0AC1-D5B1-4C25-AC47-4D08E3252D54@nominum.com> <50800059.3030503@viagenie.ca> <4E18E4F4-7E60-41F7-8700-83EF2CF1D4A4@employees.org> <219448E3-6A90-411D-A430-EDE011E5E75E@nominum.com> <50F411F4-D3C5-4CED-B9BD-5E552C61C5EE@employees.org> To: sunqi X-Mailer: Apple Mail (2.1498) Cc: "" , Ted Lemon Subject: Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-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, 18 Oct 2012 14:00:48 -0000 > This draft does proposed a contiguous mask to allocate contiguous = port-set. And the draft is a merged version of=20 > draft-wu-dhc-port-set-option-00 and draft-bajko-pripaddrassign-04. The = authors have reached the consensus to use mask for contiguous port-set = allocation, which is easy to implement both for client and server. if this proposal is also advocating a contiguous mask, then I don't = understand why you cannot use the proposal in draft-ietf-softwire-map? cheers, Ole >>>> without a "larger context" (i.e. some sort of encapsulation, how is = that supposed to work? think ARP. >>>=20 >>> Just to be clear here, the DHC working group is not proposing to = work on defining a way to share IP addresses. The DHC working group is = proposing to work on a way to convey a port range to a device which = shares IP addresses, using DHCP. Anything more than that would = definitely be out of scope for DHC. >>>=20 >>> BTW, we discussed using port ranges versus using masks; the reason = for using masks is that it's easier to do on the fast path than ranges. >>=20 >> right. draft-ietf-softwire-map uses a mask. you propose support for a = discontiguous mask, our proposal a contiguous one. anyhow, let us move = this to softwire. >>=20 >> cheers, >> Ole >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg >=20 From sunqi.csnet.thu@gmail.com Thu Oct 18 06:56:58 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDC8E21F8780 for ; Thu, 18 Oct 2012 06:56:58 -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=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 4LwXnaJBUUN8 for ; Thu, 18 Oct 2012 06:56:57 -0700 (PDT) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id D090521F877F for ; Thu, 18 Oct 2012 06:56:57 -0700 (PDT) Received: by mail-da0-f44.google.com with SMTP id h15so3454837dan.31 for ; Thu, 18 Oct 2012 06:56:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=gEIhLYvrry5Xvv07JjB0q+i8TFsLhTFGcC2BnteCAGI=; b=giEyCOBSgPl79nd9ZYd/ENk4KAcYLIbmFHHIpyk69GEMrQKgHFSuS3SXvdMPEe7TUT 3mlZb7UZq7r56SWmqQosxZDc7BdkSzoBljvrazD32+MhjPHipqDACCBksuleFQVVBhJB zHPEb2WA4ou+spjLb72flXG2m68iNnmuk+XKGEOdApsnAr/fdbwGouSJVIpyd8C9WXdY 51nH/SVHIP9c5WZ6i47zmtMoKxoeKkwCojLv9Rikevx/5aRdw0QC1BalrxOn9WJFFGf/ vEKxd7e6EGCwY05uYPLC7xNgneZB0F5OIjK7PyuhfhKranwCnnaFWs8IlLKlM4VDaARd qp6A== Received: by 10.68.203.137 with SMTP id kq9mr16626541pbc.96.1350568617503; Thu, 18 Oct 2012 06:56:57 -0700 (PDT) Received: from [192.168.1.170] ([166.111.68.233]) by mx.google.com with ESMTPS id ms11sm4063373pbc.74.2012.10.18.06.56.52 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 18 Oct 2012 06:56:56 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-2-746735862 From: sunqi In-Reply-To: <50F411F4-D3C5-4CED-B9BD-5E552C61C5EE@employees.org> Date: Thu, 18 Oct 2012 21:56:46 +0800 Message-Id: References: <9D3C0AC1-D5B1-4C25-AC47-4D08E3252D54@nominum.com> <50800059.3030503@viagenie.ca> <4E18E4F4-7E60-41F7-8700-83EF2CF1D4A4@employees.org> <219448E3-6A90-411D-A430-EDE011E5E75E@nominum.com> <50F411F4-D3C5-4CED-B9BD-5E552C61C5EE@employees.org> To: =?iso-8859-1?Q?Ole_Tr=F8an?= X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Thu, 18 Oct 2012 07:02:09 -0700 Cc: "" , Ted Lemon Subject: Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-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, 18 Oct 2012 13:56:58 -0000 --Apple-Mail-2-746735862 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Ole, This draft does proposed a contiguous mask to allocate contiguous = port-set. And the draft is a merged version of=20 draft-wu-dhc-port-set-option-00 and draft-bajko-pripaddrassign-04. The = authors have reached the consensus to use mask for contiguous port-set = allocation, which is easy to implement both for client and server. Best Regards! Qi Sun On 2012-10-18, at =E4=B8=8B=E5=8D=889:38, Ole Tr=C3=B8an wrote: >>> without a "larger context" (i.e. some sort of encapsulation, how is = that supposed to work? think ARP. >>=20 >> Just to be clear here, the DHC working group is not proposing to work = on defining a way to share IP addresses. The DHC working group is = proposing to work on a way to convey a port range to a device which = shares IP addresses, using DHCP. Anything more than that would = definitely be out of scope for DHC. >>=20 >> BTW, we discussed using port ranges versus using masks; the reason = for using masks is that it's easier to do on the fast path than ranges. >=20 > right. draft-ietf-softwire-map uses a mask. you propose support for a = discontiguous mask, our proposal a contiguous one. anyhow, let us move = this to softwire. >=20 > cheers, > Ole > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg --Apple-Mail-2-746735862 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Ole,

This draft does proposed a contiguous mask to allocate = contiguous port-set. And the draft is a merged version = of 
draft-wu-dhc-port-set-option-00 and draft-bajko-p= ripaddrassign-04. The authors have reached the consensus to use mask for = contiguous port-set allocation, which is easy to implement both for = client and server.

Best Regards!

Qi = Sun

On 2012-10-18, at =E4=B8=8B=E5=8D=889:38, Ole Tr=C3=B8an = wrote:

without a "larger context" (i.e. some sort of = encapsulation, how is that supposed to work? think = ARP.

Just to be = clear here, the DHC working group is not proposing to work on defining a = way to share IP addresses.   The DHC working group is = proposing to work on a way to convey a port range to a device which = shares IP addresses, using DHCP.   Anything more than that = would definitely be out of scope for DHC.

BTW, we = discussed using port ranges versus using masks; the reason for using = masks is that it's easier to do on the fast path than = ranges.

right. draft-ietf-softwire-map uses a mask. = you propose support for a  discontiguous mask, our proposal a = contiguous one. anyhow, let us move this to = softwire.

cheers,
Ole
_______________________________________= ________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/= mailman/listinfo/dhcwg

= --Apple-Mail-2-746735862-- From Ted.Lemon@nominum.com Thu Oct 18 07:05:39 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 846C621F8820 for ; Thu, 18 Oct 2012 07:05:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.485 X-Spam-Level: X-Spam-Status: No, score=-106.485 tagged_above=-999 required=5 tests=[AWL=0.114, 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 BljCkkncQZjF for ; Thu, 18 Oct 2012 07:05:38 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id 5F4B521F881D for ; Thu, 18 Oct 2012 07:05:38 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKUIAMrjGgfvu/UR20NoW6TuHrdh87DOw2@postini.com; Thu, 18 Oct 2012 07:05: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 BACA91B8342 for ; Thu, 18 Oct 2012 07:05:33 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id B217019005C for ; Thu, 18 Oct 2012 07:05:33 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Thu, 18 Oct 2012 07:05:33 -0700 From: Ted Lemon To: " WG" Thread-Topic: WGLC: draft-ietf-dhc-dhcpv4-over-ipv6 Thread-Index: AQHNrTmjFOygSqT8jUKurJPUyMWVCg== Date: Thu, 18 Oct 2012 14:05:33 +0000 Message-ID: <4B380728-0A9D-4B98-85C8-A723667C2676@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <0B063E325D61A04AAD1D4E3F437D670B@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dhcwg] WGLC: draft-ietf-dhc-dhcpv4-over-ipv6 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, 18 Oct 2012 14:05:39 -0000 The authors have requested a new working group last call on this document. = The document has been updated based on feedback received during the previ= ous working group last call. The authors would appreciate review and feed= back on this document. If you favor advancing it, please say so on the ma= iling list. If you oppose advancing it, also please say so and say why. We will evaluate consensus on November 1. Thanks! From simon.perreault@viagenie.ca Thu Oct 18 07:14:42 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A69A221F884A for ; Thu, 18 Oct 2012 07:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 vo5gh+sVnAK2 for ; Thu, 18 Oct 2012 07:14:42 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 053EB21F8848 for ; Thu, 18 Oct 2012 07:14:42 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:5c48:f469:9b94:d841]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 4042D415C4 for ; Thu, 18 Oct 2012 10:14:37 -0400 (EDT) Message-ID: <50800ECC.8060608@viagenie.ca> Date: Thu, 18 Oct 2012 10:14:36 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121009 Thunderbird/16.0 MIME-Version: 1.0 To: dhcwg@ietf.org References: <4B380728-0A9D-4B98-85C8-A723667C2676@nominum.com> In-Reply-To: <4B380728-0A9D-4B98-85C8-A723667C2676@nominum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv4-over-ipv6 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, 18 Oct 2012 14:14:42 -0000 Le 2012-10-18 10:05, Ted Lemon a écrit : > The authors have requested a new working group last call on this > document. The document has been updated based on feedback received > during the previous working group last call. The authors would > appreciate review and feedback on this document. If you favor > advancing it, please say so on the mailing list. If you oppose > advancing it, also please say so and say why. I favour advancing, but there's a technical issue: the draft does not specify how unicast DHCP requests are handled. Specifically in the case of an LCRA, if nothing is done the LCRA will only get broadcast packets while unicast packets will be sent directly to the DHCP server over IPv4, bypassing the LCRA. Unless the LCRA is somehow in the unicast path and is inspecting all packets, which is something you want to avoid for scalability and good architecture reasons. Suggestion: the LCRA could insert a Server Identifier Override relay sub-option [RFC5107] with its own address to make the client unicast further requests directly to the LCRA. The result would be that both broadcast and unicast DHCP messages would be converted to IPv6. With this change, the draft would be ready to go IMHO. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From pengwu.thu@gmail.com Thu Oct 18 07:32:01 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A0A321F884A for ; Thu, 18 Oct 2012 07:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 2GZYT5rrcIAB for ; Thu, 18 Oct 2012 07:32:01 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id E72F021F8846 for ; Thu, 18 Oct 2012 07:32:00 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so10529498vcb.31 for ; Thu, 18 Oct 2012 07:32:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=H1bjnFKrYE5ZwB373s0QRLeR6QRbcBMqrsJ+dwGFijk=; b=Ul22DqZT7RyFm24bjom2GRsKFeQ+CHNtHiCD5CaG1FbcjeMNxWtOm4v2UYBoLzMedt npHcwupg65EXF92L7cQiwDPEWYDv+yw4eQDGLrhFO9IwUPPwT9tZXAYF/AF6PeC9bc/8 KAdmy1BWYiX7rNFDvC/Cf9mMecsOjkIc7Sj/V5Bz12Q+8PlWh9+oWbJVwTaLCyJ543g8 LUbFyvMA+3rPDAYsYCMZXxklW9wMBKInNq6qjPfzl4LuvgVqulxxIDh15ORVa+5Qa4J4 qD6Zgjrt+xpBlLssbcCLzSQQVRC0od/yoTDcmrPPCrHGgtzED6+UCwOKK6riHvFBeMrh rBVA== MIME-Version: 1.0 Received: by 10.220.150.134 with SMTP id y6mr5604455vcv.20.1350570719706; Thu, 18 Oct 2012 07:31:59 -0700 (PDT) Received: by 10.58.163.102 with HTTP; Thu, 18 Oct 2012 07:31:56 -0700 (PDT) In-Reply-To: <507EF3DB.7080608@gmail.com> References: <9D3C0AC1-D5B1-4C25-AC47-4D08E3252D54@nominum.com> <507EF3DB.7080608@gmail.com> Date: Thu, 18 Oct 2012 22:31:56 +0800 Message-ID: From: Peng Wu To: Tom Taylor Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-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, 18 Oct 2012 14:32:01 -0000 Tom, Thanks for the clarification. Let me provide some further backgound info here as an author of draft-wu. There were two drafts on this subject, draft-bajko and draft-wu, providing different types of option formats, with slightly different concerns and effects. I gave a joint presenation on these two drafts in Vancouver. While the sense in the room was this document is needed, people did suggest to narrow the option numbers down. So, after last IETF, the authors of the two drafts along with the chairs spent quite a long time to discuss the accurate requirements, and come up with one option and a new, merged draft, which is draft-sun. Hope this can clear things up. On Thu, Oct 18, 2012 at 2:07 AM, Tom Taylor wro= te: > Rather obviously, the Wu draft was superseded by the present one. > > > On 17/10/2012 1:52 PM, Ole Tr=F8an wrote: >>> >>> The authors of this draft have asked the DHC working group to adopt it = as >>> a work item. > > ... > > >> >> what about this draft? >> http://tools.ietf.org/html/draft-wu-dhc-port-set-option-00 >> >> the MAP effort is using a different port algorithm, with a DHCPV6 option >> specified here: >> >> http://tools.ietf.org/html/draft-mdt-softwire-map-dhcp-option-03#section= -4.4 > > ... > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From mohamed.boucadair@orange.com Thu Oct 18 07:37:29 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7222721F882C for ; Thu, 18 Oct 2012 07:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.132 X-Spam-Level: X-Spam-Status: No, score=-2.132 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=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 UflrqqlCktmG for ; Thu, 18 Oct 2012 07:37:29 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id A63AF21F8849 for ; Thu, 18 Oct 2012 07:37:28 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 2CD1518C4E4; Thu, 18 Oct 2012 16:37:24 +0200 (CEST) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 1046F35C064; Thu, 18 Oct 2012 16:37:24 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Thu, 18 Oct 2012 16:37:23 +0200 From: To: Peng Wu , Tom Taylor Date: Thu, 18 Oct 2012 16:37:21 +0200 Thread-Topic: [dhcwg] Call for adoption: draft-sun-dhc-port-set-option Thread-Index: Ac2tPVqY7JuiRkOaQumqSDbWMQEs2QAACWCA Message-ID: <94C682931C08B048B7A8645303FDC9F36E64431FD1@PUEXCB1B.nanterre.francetelecom.fr> References: <9D3C0AC1-D5B1-4C25-AC47-4D08E3252D54@nominum.com> <507EF3DB.7080608@gmail.com> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.9.1.82415 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-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, 18 Oct 2012 14:37:29 -0000 Hi Peng, In addition to what you mentioned, what has been reached also among authors= of draft-sun-dhc-port-set-option is to define a simple option to convey a = contiguous port range. It was also agreed to use port masks instead of port= bounds. =20 Cheers, Med >-----Message d'origine----- >De : dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] De=20 >la part de Peng Wu >Envoy=E9 : jeudi 18 octobre 2012 16:32 >=C0 : Tom Taylor >Cc : dhcwg@ietf.org >Objet : Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-option > >Tom, > >Thanks for the clarification. >Let me provide some further backgound info here as an author=20 >of draft-wu. >There were two drafts on this subject, draft-bajko and draft-wu, >providing different types of option formats, with slightly different >concerns and effects. >I gave a joint presenation on these two drafts in Vancouver. While the >sense in the room was this document is needed, people did suggest to >narrow the option numbers down. >So, after last IETF, the authors of the two drafts along with the >chairs spent quite a long time to discuss the accurate requirements, >and come up with one option and a new, merged draft, which is >draft-sun. >Hope this can clear things up. > >On Thu, Oct 18, 2012 at 2:07 AM, Tom Taylor=20 > wrote: >> Rather obviously, the Wu draft was superseded by the present one. >> >> >> On 17/10/2012 1:52 PM, Ole Tr=F8an wrote: >>>> >>>> The authors of this draft have asked the DHC working group=20 >to adopt it as >>>> a work item. >> >> ... >> >> >>> >>> what about this draft? >>> http://tools.ietf.org/html/draft-wu-dhc-port-set-option-00 >>> >>> the MAP effort is using a different port algorithm, with a=20 >DHCPV6 option >>> specified here: >>> >>>=20 >http://tools.ietf.org/html/draft-mdt-softwire-map-dhcp-option-0 >3#section-4.4 >> >> ... >> >> _______________________________________________ >> 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 pengwu.thu@gmail.com Thu Oct 18 07:39:37 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD3A921F873D for ; Thu, 18 Oct 2012 07:39:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.363 X-Spam-Level: X-Spam-Status: No, score=-3.363 tagged_above=-999 required=5 tests=[AWL=-0.064, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 U7VefptmVD5C for ; Thu, 18 Oct 2012 07:39:37 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id D0C5921F8442 for ; Thu, 18 Oct 2012 07:39:36 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so9870275vbb.31 for ; Thu, 18 Oct 2012 07:39:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=vMWm8hVXno3fVWeKt/lm+RAZLRrVkGoPaJRBYej09DQ=; b=pa03BN5F69p7eO4SB3gtun0i70IEpQe40AOETvMIJCHwSSGMxJQdR4VOtzZxRayNyz SUnOLtNyDXxjhsnaTWJtVSZ2tLcbVDzXD8dTCLRg42oP3DIV9TbeMn1rS2JITOnL4YiL WlYxTFUNMjuuQxNMXfdgqObxm5C7F1t/0gkTd8k3RKumkLA+IrFAvmlGLTw+0We1BUUF j66YiW+4d5Zi9gEkPWSpCBiQN+K+TYdXQUMuJmKVXIopHFQ6zu8a+kYQim0f6FCH1cpK o2/Rt1iwBv64+3t439ZMMGyUGwI3+w6nznjmfhQ8GJpsTtrIM3hiM+ClKBf4XkdcopL1 gZTA== MIME-Version: 1.0 Received: by 10.58.95.65 with SMTP id di1mr15824532veb.55.1350571175924; Thu, 18 Oct 2012 07:39:35 -0700 (PDT) Received: by 10.58.163.102 with HTTP; Thu, 18 Oct 2012 07:39:35 -0700 (PDT) In-Reply-To: <4A947FFD-C1B2-4B63-A787-C27D78A33F24@employees.org> References: <9D3C0AC1-D5B1-4C25-AC47-4D08E3252D54@nominum.com> <507EF3DB.7080608@gmail.com> <5715F968-7CF0-4AD6-A622-A5151827D23B@nominum.com> <4A947FFD-C1B2-4B63-A787-C27D78A33F24@employees.org> Date: Thu, 18 Oct 2012 22:39:35 +0800 Message-ID: From: Peng Wu To: =?ISO-8859-1?Q?Ole_Tr=F8an?= Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "" , Ted Lemon Subject: Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-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, 18 Oct 2012 14:39:38 -0000 Ole, first of all, we all know that contiguous port range is a very special case of the general MAP algorithm second, I'm sensing that Ted's points is that the effort of MAP to produce non-contiguous port set is to make the ports look like "randomized" from outside, although generated in a deterministic way. That is also my understanding. But eventually it falis to achieve that once an attacker learns the deterministic algorithm. That's why we decided to remove MAP from the option list during the discussion of producing the new draft. On Thu, Oct 18, 2012 at 4:23 AM, Ole Tr=F8an wrote: > Ted, > >>> why this style of port mapping as opposed the any other? in particular = one that has consensus in softwires already... >> >> There seems to be a lot of effort going into fancy port mapping algorith= ms which do not make an attacker's job noticeably harder. The decision he= re was to simply map out a contiguous range, and allow the gateway to do po= rt randomization within that range. It is understood that the effectivene= ss of port range randomization goes down as the port range grows smaller, b= ut it's also understood that there isn't anything we can actually do about = this=97address sharing unavoidably makes guessing ports easier. > > the port mapping algorithm I'm talking about (http://tools.ietf.org/html/= draft-ietf-softwire-map-02) is > a) not fancy > b) does not do any port randomization. > > which one are you referring to? > >> Any deterministic algorithm that isn't a straightforward port range simp= ly adds complexity without adding benefit: there's nothing secret about it= =97an attacker can just reverse it, and there is no way to keep secret from= the attacker what algorithm has been chosen. Consequently these alternat= ive algorithms were removed from consideration. > > in agreement with you there. which ones did you remove? > >> Seeded random number algorithms were discussed, but implementation was c= onsidered unlikely, and so it was decided that they weren't worth bothering= with. My own conversations with service providers have indicated a stron= g preference for simplicity here to avoid interoperability problems when im= plementations accidentally differ. > > agree. > >> The MAP folks should just use port ranges. There is no need for them t= o do their own port set allocation option. > > > they do just use port ranges. please read the proposal. > > why do you want to standardize yet another representation of port ranges?= if you have to, do it in softwires (and don't use discontiguous masks). > > cheers, > Ole > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From sunqi.thu@gmail.com Thu Oct 18 07:42:54 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1499221F8754 for ; Thu, 18 Oct 2012 07:42:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.727, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 GNQhWVuS2Lkv for ; Thu, 18 Oct 2012 07:42:53 -0700 (PDT) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 727D121F8442 for ; Thu, 18 Oct 2012 07:42:53 -0700 (PDT) Received: by mail-da0-f44.google.com with SMTP id h15so3474057dan.31 for ; Thu, 18 Oct 2012 07:42:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=WgOD6xxozzphfnVSOWPk3VxVnjmUKLzpofbsrcU5Bd4=; b=oe80bVN7SYusCUvIzCljocmaQDWEUjubwcMKb4jQKeNRPicNgtKNjuQC/GuD/7LHFv DFJvnwxmg9ylnbd6VmiSahQXqhUwnC2hLYXCacTL+61y3QF7iVsgs86MmvkplrB6TEvD uAj//IA5m6+MMrco30tcULc2qi4xLjqP9Ul6B633AZMqUcau5Jk7n5QSsivVu1Ey6vAp Mi7iKBsDjoDY/1Blm43tuqiiG61wpp1Br1H9/HFVhS6pDapBF4UO+bv49JUCGb3oMFHB DtJbTaNksDVdKvY1UtoOXWTUQeEih2LD8q3iroCs3lwMPtYDWxgAafOmHJTYO/AbtUZL reJg== Received: by 10.66.73.6 with SMTP id h6mr59990974pav.69.1350571373063; Thu, 18 Oct 2012 07:42:53 -0700 (PDT) Received: from [192.168.1.170] ([166.111.68.233]) by mx.google.com with ESMTPS id vz8sm14330209pbc.63.2012.10.18.07.42.48 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 18 Oct 2012 07:42:51 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=utf-8 From: Qi Sun In-Reply-To: Date: Thu, 18 Oct 2012 22:42:42 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <6ED6C0E5-48E1-4E10-A190-40998201D449@gmail.com> References: <9D3C0AC1-D5B1-4C25-AC47-4D08E3252D54@nominum.com> <50800059.3030503@viagenie.ca> <4E18E4F4-7E60-41F7-8700-83EF2CF1D4A4@employees.org> <219448E3-6A90-411D-A430-EDE011E5E75E@nominum.com> <50F411F4-D3C5-4CED-B9BD-5E552C61C5EE@employees.org> To: =?iso-8859-1?Q?Ole_Tr=F8an?= X-Mailer: Apple Mail (2.1084) Cc: "" , Ted Lemon Subject: Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-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, 18 Oct 2012 14:42:54 -0000 Hi Ole, > if this proposal is also advocating a contiguous mask, then I don't = understand why you cannot use the proposal in draft-ietf-softwire-map? The proposal in draft-ietf-softwire-map includes case of allocating = non-contiguous port-sets to a CE. Non-contiguous port-set can't make it = harder to guess the port, with extra effort for implementation. A = contiguous port-set is enough and can be achieved easily. Thanks, Qi Sun On 2012-10-18, at =E4=B8=8B=E5=8D=8810:00, Ole Tr=C3=B8an wrote: >> This draft does proposed a contiguous mask to allocate contiguous = port-set. And the draft is a merged version of=20 >> draft-wu-dhc-port-set-option-00 and draft-bajko-pripaddrassign-04. = The authors have reached the consensus to use mask for contiguous = port-set allocation, which is easy to implement both for client and = server. >=20 > if this proposal is also advocating a contiguous mask, then I don't = understand why you cannot use the proposal in draft-ietf-softwire-map? >=20 > cheers, > Ole >=20 >>>>> without a "larger context" (i.e. some sort of encapsulation, how = is that supposed to work? think ARP. >>>>=20 >>>> Just to be clear here, the DHC working group is not proposing to = work on defining a way to share IP addresses. The DHC working group is = proposing to work on a way to convey a port range to a device which = shares IP addresses, using DHCP. Anything more than that would = definitely be out of scope for DHC. >>>>=20 >>>> BTW, we discussed using port ranges versus using masks; the reason = for using masks is that it's easier to do on the fast path than ranges. >>>=20 >>> right. draft-ietf-softwire-map uses a mask. you propose support for = a discontiguous mask, our proposal a contiguous one. anyhow, let us = move this to softwire. >>>=20 >>> cheers, >>> Ole >>> _______________________________________________ >>> dhcwg mailing list >>> dhcwg@ietf.org >>> https://www.ietf.org/mailman/listinfo/dhcwg >>=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From pengwu.thu@gmail.com Thu Oct 18 07:45:21 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A12221F8754 for ; Thu, 18 Oct 2012 07:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.355 X-Spam-Level: X-Spam-Status: No, score=-3.355 tagged_above=-999 required=5 tests=[AWL=-0.056, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 HY8bByA3HHYa for ; Thu, 18 Oct 2012 07:45:20 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5BEB321F86D5 for ; Thu, 18 Oct 2012 07:45:20 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so10553720vcb.31 for ; Thu, 18 Oct 2012 07:45:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ppI5q4gWPz1dGJbd8Md0ds9sznMOzen5guo+zO4LhgU=; b=vG12hRPMBhyNpwi3X06MWr0qfvfTXOri7R0wZRmg+wlOXUnCjY/P1+qJ2ayO3/oBJA Hty3xAD2WePGNks/qAIP5ltFfycU6/n4rQ2kBtiGE6ZQo13SAdYq3TRzVi8xqljA4TcO fFRb4NkWR9DgQAHpna0m4TnKQz8eEmoRUs4VOaLeiEfuvqb8c2hbX6NaY3R9zlx1Xq82 9VkRcFHbIrM6Ecu5WffK1Aqtk75ImRKbV/Fmp8BYBhjZedChu2W3K6Hh933d3l2BFViv osQFX9Yk3yovAqBQ/MwsWLfTmCFc99Zf3jXW9tG87PD5/ZDZrGanFAH6e8zZTuS5fa78 e4oA== MIME-Version: 1.0 Received: by 10.52.89.172 with SMTP id bp12mr12412049vdb.19.1350571519734; Thu, 18 Oct 2012 07:45:19 -0700 (PDT) Received: by 10.58.163.102 with HTTP; Thu, 18 Oct 2012 07:45:19 -0700 (PDT) In-Reply-To: References: <9D3C0AC1-D5B1-4C25-AC47-4D08E3252D54@nominum.com> <50800059.3030503@viagenie.ca> <4E18E4F4-7E60-41F7-8700-83EF2CF1D4A4@employees.org> <219448E3-6A90-411D-A430-EDE011E5E75E@nominum.com> <50F411F4-D3C5-4CED-B9BD-5E552C61C5EE@employees.org> Date: Thu, 18 Oct 2012 22:45:19 +0800 Message-ID: From: Peng Wu To: =?ISO-8859-1?Q?Ole_Tr=F8an?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sunqi , "" , Ted Lemon Subject: Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-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, 18 Oct 2012 14:45:21 -0000 If we only need contiguous port range as you said, we only need a contiguous mask and that's all. Perfect match. No other MAP parameters or non-contiguous port set format as an outcome of MAP. On Thu, Oct 18, 2012 at 10:00 PM, Ole Tr=F8an wrote: >> This draft does proposed a contiguous mask to allocate contiguous port-s= et. And the draft is a merged version of >> draft-wu-dhc-port-set-option-00 and draft-bajko-pripaddrassign-04. The a= uthors have reached the consensus to use mask for contiguous port-set alloc= ation, which is easy to implement both for client and server. > > if this proposal is also advocating a contiguous mask, then I don't under= stand why you cannot use the proposal in draft-ietf-softwire-map? > > cheers, > Ole > From otroan@employees.org Thu Oct 18 07:54:19 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F13721F86BB for ; Thu, 18 Oct 2012 07:54:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.258 X-Spam-Level: X-Spam-Status: No, score=-10.258 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 WnzCsGPLYCvJ for ; Thu, 18 Oct 2012 07:54:19 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 87DFD21F8619 for ; Thu, 18 Oct 2012 07:54:18 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAKQXgFCQ/khR/2dsb2JhbABFwDyBCIIgAQEBAwESAQodPxALRlcGNYdcBpxSoDuROmADpDSBa4Jx X-IronPort-AV: E=Sophos;i="4.80,608,1344211200"; d="scan'208";a="145476127" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 18 Oct 2012 14:53:58 +0000 Received: from dhcp-lys01-vla250-10-147-112-212.cisco.com (dhcp-lys01-vla250-10-147-112-212.cisco.com [10.147.112.212]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9IErvPd025822 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 18 Oct 2012 14:53:58 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <6ED6C0E5-48E1-4E10-A190-40998201D449@gmail.com> Date: Thu, 18 Oct 2012 16:53:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9D3C0AC1-D5B1-4C25-AC47-4D08E3252D54@nominum.com> <50800059.3030503@viagenie.ca> <4E18E4F4-7E60-41F7-8700-83EF2CF1D4A4@employees.org> <219448E3-6A90-411D-A430-EDE011E5E75E@nominum.com> <50F411F4-D3C5-4CED-B9BD-5E552C61C5EE@employees.org> <6ED6C0E5-48E1-4E10-A190-40998201D449@gmail.com> To: Qi Sun X-Mailer: Apple Mail (2.1498) Cc: "" , Ted Lemon Subject: Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-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, 18 Oct 2012 14:54:19 -0000 >> if this proposal is also advocating a contiguous mask, then I don't = understand why you cannot use the proposal in draft-ietf-softwire-map? >=20 > The proposal in draft-ietf-softwire-map includes case of allocating = non-contiguous port-sets to a CE. Non-contiguous port-set can't make it = harder to guess the port, with extra effort for implementation. A = contiguous port-set is enough and can be achieved easily. MAP isn't encoded the way it is to make it hard to guess, it is to avoid = the well known ports, without reserving a particular "port set id" as = you call it. with an offset =3D 0, you get your scheme with MAP. what you appear to describe is what I previously called a "port prefix", = and something you could represent as: /. e.g. 0x14/6 to use your example in the = draft. again, what are your benefits over the existing MAP proposal that has = already achieved consensus? why do we need yet another one? cheers, Ole= From bingxuere@gmail.com Thu Oct 18 07:56:55 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81C6021F87C6 for ; Thu, 18 Oct 2012 07:56:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 EsFrbL7gllWc for ; Thu, 18 Oct 2012 07:56:54 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id C0F3521F86FC for ; Thu, 18 Oct 2012 07:56:54 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id v19so10380091obq.31 for ; Thu, 18 Oct 2012 07:56:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=iLCM4h3s2/PNb/a30Z7XzkJ6a4mNugouKWm5xfqNhDs=; b=A5ZU5vFz32HTwUrKmcEFLY97CIiNew0L8wkqjatedIRnSkinu6v8Ro6TtyHK1UhREy GmH8ACEsxurPEw6OSuzmGv8sTeG+uxuuO7YP4e8n1uyUM95vLscpsPd3noa7kLIyBTME DkHCmG6zP/ki/8VAK+IifZmjWXyGWF3rgNXz5Z2ULQVvpQ9EXMUIW1Inlqn7LI4WGwvl 4cYS0PvGR5TwwKe4zceTMXxRXpVtUSO0PLVQQCaoDwKDnBidoayWxgL4SYIDo8tQ7lFG 5kS1bEIXf5NhEFIV37CD9qtqgk7EvORQubM1Lbdf4bpWOMnUoTuhpxipHkRKTquQKpmJ lgWg== Received: by 10.60.2.161 with SMTP id 1mr18494299oev.48.1350572214311; Thu, 18 Oct 2012 07:56:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.34.133 with HTTP; Thu, 18 Oct 2012 07:56:14 -0700 (PDT) In-Reply-To: References: <9D3C0AC1-D5B1-4C25-AC47-4D08E3252D54@nominum.com> <50800059.3030503@viagenie.ca> <4E18E4F4-7E60-41F7-8700-83EF2CF1D4A4@employees.org> <219448E3-6A90-411D-A430-EDE011E5E75E@nominum.com> <50F411F4-D3C5-4CED-B9BD-5E552C61C5EE@employees.org> From: Qiong Date: Thu, 18 Oct 2012 22:56:14 +0800 Message-ID: To: Peng Wu Content-Type: multipart/alternative; boundary=e89a8f923de413dc1404cc56995b Cc: sunqi , "" , Ted Lemon Subject: Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-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, 18 Oct 2012 14:56:55 -0000 --e89a8f923de413dc1404cc56995b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable indeed. The contiguous port mask is one example of MAP algorithm. But we hope to simplify it from both implementation and operational point of view, by removing all these parameters and algorithms. Contiguous port-set using port mask is all we need, so we do not need anything more. And besides, what we need is a DHCPv4 option, not DHCPv6. Best wishes Qiong On Thu, Oct 18, 2012 at 10:45 PM, Peng Wu wrote: > If we only need contiguous port range as you said, we only need a > contiguous mask and that's all. Perfect match. No other MAP parameters > or non-contiguous port set format as an outcome of MAP. > > On Thu, Oct 18, 2012 at 10:00 PM, Ole Tr=C3=B8an w= rote: > >> This draft does proposed a contiguous mask to allocate contiguous > port-set. And the draft is a merged version of > >> draft-wu-dhc-port-set-option-00 and draft-bajko-pripaddrassign-04. The > authors have reached the consensus to use mask for contiguous port-set > allocation, which is easy to implement both for client and server. > > > > if this proposal is also advocating a contiguous mask, then I don't > understand why you cannot use the proposal in draft-ietf-softwire-map? > > > > cheers, > > Ole > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > --=20 =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=3D=3D=3D=3D=3D Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/* PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * =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=3D=3D=3D=3D=3D=3D --e89a8f923de413dc1404cc56995b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable indeed. The contiguous port mask is one example of MAP algorithm. But we ho= pe to simplify it from both implementation and operational point of view, b= y removing all these parameters and algorithms. Contiguous port-set using p= ort mask is all we need, so we do not need anything more.

And besides, what we need is a DHCPv4 option, not DHCPv6.

Best w= ishes
Qiong=C2=A0

On Thu, Oct 18, 201= 2 at 10:45 PM, Peng Wu <pengwu.thu@gmail.com> wrote:
If we only need contiguous port range as you= said, we only need a
contiguous mask and that's all. Perfect match. No other MAP parameters<= br> or non-contiguous port set format as an outcome of MAP.

On Thu, Oct 18, 2012 at 10:00 PM, Ole Tr=C3=B8an <otroan@employees.org> wrote:
>> This draft does proposed a contiguous mask to allocate contiguous = port-set. And the draft is a merged version of
>> draft-wu-dhc-port-set-option-00 and draft-bajko-pripaddrassign-04.= The authors have reached the consensus to use mask for contiguous port-set= allocation, which is easy to implement both for client and server.
>
> if this proposal is also advocating a contiguous mask, then I don'= t understand why you cannot use the proposal in draft-ietf-softwire-map? >
> cheers,
> Ole
>
_____________________________= __________________
dhcwg mailing list
dhcwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dhcwg



--
=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=3D=3D=3D=3D=3D
Qiong Sun
Chin= a Telecom Beijing Research Institude


Open source code:
lightw= eight 4over6: http://sourceforge.net/projects/laft6/
PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/
=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=3D=3D=3D=3D=3D=3D

--e89a8f923de413dc1404cc56995b-- From sunqi.thu@gmail.com Thu Oct 18 07:59:06 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD09D21F8743 for ; Thu, 18 Oct 2012 07:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.373 X-Spam-Level: X-Spam-Status: No, score=-3.373 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 H3LXJ4Sk3tsT for ; Thu, 18 Oct 2012 07:59:06 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3B04D21F8741 for ; Thu, 18 Oct 2012 07:59:06 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id s14so7804391qcg.31 for ; Thu, 18 Oct 2012 07:59:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QOzYsETc+O1YzBzWJBqsTDjiPgl8wFjaMaxWN8JSjDg=; b=AYQSxu6CUNO3VdJUSxKuKXjjBkJ6zW7BUwkRhCuSdx5F0Ve2K1umqjESNpXzsvE+g+ pAk8IZzQuCbbsqjyTH4sernwKQSKVY9aoxijSdH5qQvfiV5zpR3Ljyuowa1xzlXziY6J pmPqZgFi2ymH7ByBLiMsh8k6fB7aa6TQK0sQCkcyf9/TGXxbqjqAse07d/LsMd0mupfX ftzPcTpU77vxrzCKZI6sYgKQDXzJBM5Dgfo9La/ZdFFXuES64DvR4B2k0UJRkhHFpGHq 8rlOCripgpDPxOGYHBZwEpNCEdGKw1+tLTlf0ey5VW1nWDucEo9LtTz86aisnvLfTbb/ hCyQ== MIME-Version: 1.0 Received: by 10.49.3.234 with SMTP id f10mr46057691qef.45.1350572345771; Thu, 18 Oct 2012 07:59:05 -0700 (PDT) Received: by 10.49.50.105 with HTTP; Thu, 18 Oct 2012 07:59:05 -0700 (PDT) In-Reply-To: References: <9D3C0AC1-D5B1-4C25-AC47-4D08E3252D54@nominum.com> <50800059.3030503@viagenie.ca> <4E18E4F4-7E60-41F7-8700-83EF2CF1D4A4@employees.org> <219448E3-6A90-411D-A430-EDE011E5E75E@nominum.com> <50F411F4-D3C5-4CED-B9BD-5E552C61C5EE@employees.org> <6ED6C0E5-48E1-4E10-A190-40998201D449@gmail.com> Date: Thu, 18 Oct 2012 22:59:05 +0800 Message-ID: From: Qi Sun To: =?ISO-8859-1?Q?Ole_Tr=F8an?= Content-Type: multipart/alternative; boundary=047d7bb03e68e9c4f104cc56a092 Cc: "" , Ted Lemon Subject: Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-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, 18 Oct 2012 14:59:07 -0000 --047d7bb03e68e9c4f104cc56a092 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable again, what are your benefits over the existing MAP proposal that has already achieved consensus? [Qi] The contiguous port-set with port mask is simple and clean. And it's easier to understand, especially as a DHCP option. BR, Qi Sun On Thu, Oct 18, 2012 at 10:53 PM, Ole Tr=F8an wrote: > >> if this proposal is also advocating a contiguous mask, then I don't > understand why you cannot use the proposal in draft-ietf-softwire-map? > > > > The proposal in draft-ietf-softwire-map includes case of allocating > non-contiguous port-sets to a CE. Non-contiguous port-set can't make it > harder to guess the port, with extra effort for implementation. A > contiguous port-set is enough and can be achieved easily. > > MAP isn't encoded the way it is to make it hard to guess, it is to avoid > the well known ports, without reserving a particular "port set id" as you > call it. > > with an offset =3D 0, you get your scheme with MAP. > > what you appear to describe is what I previously called a "port prefix", > and something you could represent as: > /. e.g. 0x14/6 to use your example in the draft= . > > again, what are your benefits over the existing MAP proposal that has > already achieved consensus? > why do we need yet another one? > > cheers, > Ole --047d7bb03e68e9c4f104cc56a092 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable again, what are your benefits over the existing MAP proposal that has alrea= dy achieved consensus?

[Qi] The contiguous port-set with= port mask is simple and clean. And it's easier to understand, especial= ly as a DHCP option.

BR,
Qi Sun

On Thu, Oct 18, 2012 at 10:53 PM, Ole Tr=F8an <= otroan@employees.= org> wrote:
>> if this proposal = is also advocating a contiguous mask, then I don't understand why you c= annot use the proposal in draft-ietf-softwire-map?
>
> The proposal in draft-ietf-softwire-map includes case of =A0allocating= non-contiguous port-sets to a CE. Non-contiguous port-set can't make i= t harder to guess the port, with extra effort for implementation. =A0A cont= iguous port-set is enough and can be achieved easily.

MAP isn't encoded the way it is to make it hard to guess, it is t= o avoid the well known ports, without reserving a particular "port set= id" as you call it.

with an offset =3D 0, you get your scheme with MAP.

what you appear to describe is what I previously called a "port prefix= ", and something you could represent as:
<port>/<port-prefix length>. e.g. 0x14/6 to use your example in= the draft.

again, what are your benefits over the existing MAP proposal that has alrea= dy achieved consensus?
why do we need yet another one?

cheers,
Ole

--047d7bb03e68e9c4f104cc56a092-- From wdec.ietf@gmail.com Thu Oct 18 08:06:10 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDCB921F882E for ; Thu, 18 Oct 2012 08:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.273 X-Spam-Level: X-Spam-Status: No, score=-3.273 tagged_above=-999 required=5 tests=[AWL=0.325, 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 OPKjdeh1k6mE for ; Thu, 18 Oct 2012 08:06:09 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9F6B121F882B for ; Thu, 18 Oct 2012 08:06:08 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id d4so5055354eek.31 for ; Thu, 18 Oct 2012 08:05:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dB89y6mExDu0CbrK12qckiv5aps0IZGhRT/LqtWfIa8=; b=C93/50Ihn8mdBKcksgbpTHTZ2uIR6nwk4GBuvfbdXX8YJudO53HwP1nsl5DF9wS2rW gNVD6cpQsnCcZ94gtOjin6CgsrHAyRB4l0Wrlbv72vkuVG++ZhobaSccNGQjth67E6H+ 66SMrOJ0+Ohh/tsPz1I6gOuUcCDrMhm4CpXlVs1iBnI+86OstMHEIfeyJ09gxl2hLWCN KhjLMwwAkDB97pCw9txUeBDiXaiz3lHdClz/bf/4NkJxvjKFsQhIKqEZ6UY9SxDDgfUY FEg+eRXuroiKjeW6fgmWS/CVWQx0gu5agGnuU1aK8aVW/OHw4evXqnzq8QWUlLb8d5Yu nUGg== MIME-Version: 1.0 Received: by 10.14.207.9 with SMTP id m9mr31779329eeo.5.1350572759390; Thu, 18 Oct 2012 08:05:59 -0700 (PDT) Received: by 10.14.128.71 with HTTP; Thu, 18 Oct 2012 08:05:59 -0700 (PDT) In-Reply-To: <219448E3-6A90-411D-A430-EDE011E5E75E@nominum.com> References: <9D3C0AC1-D5B1-4C25-AC47-4D08E3252D54@nominum.com> <50800059.3030503@viagenie.ca> <4E18E4F4-7E60-41F7-8700-83EF2CF1D4A4@employees.org> <219448E3-6A90-411D-A430-EDE011E5E75E@nominum.com> Date: Thu, 18 Oct 2012 17:05:59 +0200 Message-ID: From: Wojciech Dec To: Ted Lemon Content-Type: multipart/alternative; boundary=047d7b33dc3091183104cc56b9d2 Cc: "" Subject: Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-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, 18 Oct 2012 15:06:10 -0000 --047d7b33dc3091183104cc56b9d2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 18 October 2012 15:34, Ted Lemon wrote: > On Oct 18, 2012, at 9:28 AM, Ole Tr=F8an > wrote: > > without a "larger context" (i.e. some sort of encapsulation, how is tha= t > supposed to work? think ARP. > > Just to be clear here, the DHC working group is not proposing to work on > defining a way to share IP addresses. The DHC working group is proposin= g > to work on a way to convey a port range to a device which shares IP > addresses, using DHCP. Anything more than that would definitely be out = of > scope for DHC. > It may be worthwhile to ask "why" then are these ranges needed, if not for the specific solutions in softwires? The sharing of IP addresses on a "regular v4" network has been documented as "bad", http://tools.ietf.org/html/draft-thaler-port-restricted-ip-issues-00 Now, given that there are several nuances of the solutions for "v4 networks over v6", with address sharing, it stands to reason that the solution group defining these should also define the option and consult DHC accordingly, rather than the other way round. Regards, Woj. > > BTW, we discussed using port ranges versus using masks; the reason for > using masks is that it's easier to do on the fast path than ranges. > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > --047d7b33dc3091183104cc56b9d2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 18 October 2012 15:34, Ted Lemon <Ted.Lemon@nominum.com> wrote:
On Oct 18, 2012, at 9:28 AM, Ole Tr=F8an <otroan@employees.org>
=A0wrote:
> without a "larger context" (i.e. some sort of encapsulation,= how is that supposed to work? think ARP.

Just to be clear here, the DHC working group is not proposing to work= on defining a way to share IP addresses. =A0 The DHC working group is prop= osing to work on a way to convey a port range to a device which shares IP a= ddresses, using DHCP. =A0 Anything more than that would definitely be out o= f scope for DHC.

It may be worthwhile to ask "why" then are = these ranges needed, if not for the specific solutions in softwires?
The= sharing of IP addresses on a "regular v4" network has been=A0 do= cumented as "bad", http://tools.ietf.org/html/draft-thaler-= port-restricted-ip-issues-00

Now, given that there are several nuances of the solutions for "v4= networks over v6", with address sharing, it stands to reason that the= solution group defining these should also define the option and consult DH= C accordingly, rather than the other way round.

Regards,
Woj.

BTW, we discussed using port ranges versus using masks; the reason for usin= g masks is that it's easier to do on the fast path than ranges.

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

--047d7b33dc3091183104cc56b9d2-- From Ted.Lemon@nominum.com Thu Oct 18 08:31:49 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C18FD21F8751 for ; Thu, 18 Oct 2012 08:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.487 X-Spam-Level: X-Spam-Status: No, score=-106.487 tagged_above=-999 required=5 tests=[AWL=0.112, 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 K5r13q-sx8wr for ; Thu, 18 Oct 2012 08:31:49 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id B8BED21F8741 for ; Thu, 18 Oct 2012 08:31:48 -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 DSNKUIAg5GWvw0B5RZjkgnnHeChF4XIGyuAw@postini.com; Thu, 18 Oct 2012 08: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 E28BA1B8344 for ; Thu, 18 Oct 2012 08:31:47 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id D8E8419005C; Thu, 18 Oct 2012 08:31:47 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Thu, 18 Oct 2012 08:31:48 -0700 From: Ted Lemon To: Simon Perreault Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-dhcpv4-over-ipv6 Thread-Index: AQHNrTmjFOygSqT8jUKurJPUyMWVCpe/kLMAgAAVjoA= Date: Thu, 18 Oct 2012 15:31:46 +0000 Message-ID: <5E8961DA-7D45-433C-A73F-FC6D1C230E67@nominum.com> References: <4B380728-0A9D-4B98-85C8-A723667C2676@nominum.com> <50800ECC.8060608@viagenie.ca> In-Reply-To: <50800ECC.8060608@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <97D0BAAC46E0E24E82795EB0425C9C82@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv4-over-ipv6 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, 18 Oct 2012 15:31:49 -0000 On Oct 18, 2012, at 10:14 AM, Simon Perreault = wrote: > I favour advancing, but there's a technical issue: the draft does not spe= cify how unicast DHCP requests are handled. Specifically in the case of an = LCRA, if nothing is done the LCRA will only get broadcast packets while uni= cast packets will be sent directly to the DHCP server over IPv4, bypassing = the LCRA. Unless the LCRA is somehow in the unicast path and is inspecting = all packets, which is something you want to avoid for scalability and good = architecture reasons. Renewals would automatically go down the tunnel, so unless the tunnel doesn= 't provide a route to the DHCP server, I don't think this is a problem. A= m I missing something? From pengwu.thu@gmail.com Thu Oct 18 08:34:30 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FD2621F878A for ; Thu, 18 Oct 2012 08:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 jHfaHB1CkttI for ; Thu, 18 Oct 2012 08:34:29 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8B39621F8786 for ; Thu, 18 Oct 2012 08:34:29 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so10631677vcb.31 for ; Thu, 18 Oct 2012 08:34:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=H8bjyL1z4pgJeZcxns2vFuUNy7IscQm2KKs4qQO6z7I=; b=p7lIz6rxCULao3w8kUjLhzFYIhgLtmauc6feeuy3+tCZPz3af/phhFL2fSX2L49lf/ co2qz1jirTGZcGIwrZeodRTBYi8TyVq7Oc0xKIb4TYTsA9W9T2reQR/G5KSEK2rO3ikr VwHYvfO5zrKHtrTIQdI/8nZujwJrGJplvTR8TV/mmCDh2SfSCA2zEoEOQoFpz+L9VK1H QdrXFEsz60cjxRXIKFZAlaFAFSl9ZPdF35/4jsd6J6SiscIcqFr1GcCHRlwY1x1m7Gl0 1Re0lrRf3hsUgUo1O7hGefAObZK1CZ3Wn5i/hxNk6NpABeIxOZHFAJzupCAEf00rK1ZU pejg== MIME-Version: 1.0 Received: by 10.221.2.10 with SMTP id ns10mr5980781vcb.25.1350574468923; Thu, 18 Oct 2012 08:34:28 -0700 (PDT) Received: by 10.58.163.102 with HTTP; Thu, 18 Oct 2012 08:34:28 -0700 (PDT) In-Reply-To: <50800ECC.8060608@viagenie.ca> References: <4B380728-0A9D-4B98-85C8-A723667C2676@nominum.com> <50800ECC.8060608@viagenie.ca> Date: Thu, 18 Oct 2012 23:34:28 +0800 Message-ID: From: Peng Wu To: Simon Perreault Content-Type: text/plain; charset=ISO-8859-1 Cc: dhcwg@ietf.org Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv4-over-ipv6 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, 18 Oct 2012 15:34:30 -0000 Hi simon > I favour advancing, but there's a technical issue: the draft does not > specify how unicast DHCP requests are handled. Specifically in the case of > an LCRA, if nothing is done the LCRA will only get broadcast packets while > unicast packets will be sent directly to the DHCP server over IPv4, > bypassing the LCRA. Unless the LCRA is somehow in the unicast path and is > inspecting all packets, which is something you want to avoid for scalability > and good architecture reasons. The current draft kind of leave the unicast DHCP requests as it is. For example, in public 4over6 case where a tunnel is provided, it reaches the server id address through the tunnel. While in implmentation, a server can chose to forbid the server id option and force the client to broadcast DHCP request. > > Suggestion: the LCRA could insert a Server Identifier Override relay > sub-option [RFC5107] with its own address to make the client unicast further > requests directly to the LCRA. The result would be that both broadcast and > unicast DHCP messages would be converted to IPv6. I haven't check RFC5107 yet but this also sounds possible. Will think this through. From simon.perreault@viagenie.ca Thu Oct 18 08:35:19 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2E6721F8794 for ; Thu, 18 Oct 2012 08:35:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 FDmB0YPVOKZ9 for ; Thu, 18 Oct 2012 08:35:19 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4860921F8786 for ; Thu, 18 Oct 2012 08:35:19 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:5c48:f469:9b94:d841]) by jazz.viagenie.ca (Postfix) with ESMTPSA id B19B641630; Thu, 18 Oct 2012 11:35:18 -0400 (EDT) Message-ID: <508021B6.2060906@viagenie.ca> Date: Thu, 18 Oct 2012 11:35:18 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121009 Thunderbird/16.0 MIME-Version: 1.0 To: Ted Lemon References: <4B380728-0A9D-4B98-85C8-A723667C2676@nominum.com> <50800ECC.8060608@viagenie.ca> <5E8961DA-7D45-433C-A73F-FC6D1C230E67@nominum.com> In-Reply-To: <5E8961DA-7D45-433C-A73F-FC6D1C230E67@nominum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "" Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv4-over-ipv6 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, 18 Oct 2012 15:35:19 -0000 Le 2012-10-18 11:31, Ted Lemon a écrit : > On Oct 18, 2012, at 10:14 AM, Simon Perreault wrote: >> I favour advancing, but there's a technical issue: the draft does not specify how unicast DHCP requests are handled. Specifically in the case of an LCRA, if nothing is done the LCRA will only get broadcast packets while unicast packets will be sent directly to the DHCP server over IPv4, bypassing the LCRA. Unless the LCRA is somehow in the unicast path and is inspecting all packets, which is something you want to avoid for scalability and good architecture reasons. > > Renewals would automatically go down the tunnel, so unless the tunnel doesn't provide a route to the DHCP server, I don't think this is a problem. Am I missing something? Yes you're missing something. ;) The message would indeed go down the tunnel to the server. But remember that the CPE only has a partial IPv4 address on that tunnel interface. Messages sent from the server to the CPE's IPv4 address at port 68 will reach the CPE whose port range includes 68, not necessarily the CPE that sent the request. The result is that messages from client to server will work, but the reply will be lost. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From Ted.Lemon@nominum.com Thu Oct 18 08:36:51 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9490621F882D for ; Thu, 18 Oct 2012 08:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.488 X-Spam-Level: X-Spam-Status: No, score=-106.488 tagged_above=-999 required=5 tests=[AWL=0.111, 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 kTxyLtC63kYa for ; Thu, 18 Oct 2012 08:36:51 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id E7A2D21F87A9 for ; Thu, 18 Oct 2012 08:36:50 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKUIAiEkFefc3laRfbWlRLr+PFchPEgccP@postini.com; Thu, 18 Oct 2012 08:36:51 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 1F7E41B8344 for ; Thu, 18 Oct 2012 08:36:50 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 11E1D19005D for ; Thu, 18 Oct 2012 08:36:50 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Thu, 18 Oct 2012 08:36:50 -0700 From: Ted Lemon To: dhc WG Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt Thread-Index: Ac2X8ddMOw/OIH/tQHCVi0DiBXN4ZAVjzfUA Date: Thu, 18 Oct 2012 15:36:48 +0000 Message-ID: <7809F7E0-1EFD-491F-84AB-0F6DE8685927@nominum.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <342831EF6F627840B377EF6B5DB53076@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 15:36:51 -0000 On Sep 21, 2012, at 8:08 AM, Ted Lemon wrote: > We will evaluate consensus on October 5.=20 Well here it is, October 5, and it's time to evaluate consensus. Oh wait,= it's October 18. But anyway, there were about ten participants in favor = of advancing, and none opposed. Two participants, Bernie and Tim, had sug= gestions to clarify the text. Could the authors please sync up with Tim a= nd Bernie to get those fixes in and then post an updated document? Once w= e have the updated doc, I will submit a shepherd doc to the IESG. From Ted.Lemon@nominum.com Thu Oct 18 08:44:39 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B06521F87FB for ; Thu, 18 Oct 2012 08:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.49 X-Spam-Level: X-Spam-Status: No, score=-106.49 tagged_above=-999 required=5 tests=[AWL=0.109, 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 pHxJsONQA-hP for ; Thu, 18 Oct 2012 08:44:38 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 5913821F87E3 for ; Thu, 18 Oct 2012 08:44:38 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKUIAj5rnSHHse7F+mbuYk0Ab+wrdU9G2b@postini.com; Thu, 18 Oct 2012 08:44: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 9820D1B8344 for ; Thu, 18 Oct 2012 08:44:37 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 8FC3919005C; Thu, 18 Oct 2012 08:44:37 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Thu, 18 Oct 2012 08:44:37 -0700 From: Ted Lemon To: Simon Perreault Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-dhcpv4-over-ipv6 Thread-Index: AQHNrTmjFOygSqT8jUKurJPUyMWVCpe/kLMAgAAVjoCAAAD+AIAAApkA Date: Thu, 18 Oct 2012 15:44:36 +0000 Message-ID: References: <4B380728-0A9D-4B98-85C8-A723667C2676@nominum.com> <50800ECC.8060608@viagenie.ca> <5E8961DA-7D45-433C-A73F-FC6D1C230E67@nominum.com> <508021B6.2060906@viagenie.ca> In-Reply-To: <508021B6.2060906@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <38124E2456618A438D202AABDA77FCBA@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv4-over-ipv6 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, 18 Oct 2012 15:44:39 -0000 On Oct 18, 2012, at 11:35 AM, Simon Perreault wrote: > The message would indeed go down the tunnel to the server. But remember t= hat the CPE only has a partial IPv4 address on that tunnel interface. Messa= ges sent from the server to the CPE's IPv4 address at port 68 will reach th= e CPE whose port range includes 68, not necessarily the CPE that sent the r= equest. The result is that messages from client to server will work, but th= e reply will be lost. Ah, I see. You are talking about lightweight 4over6. This is indeed a p= roblem, but only when address sharing is in use. The dhcpv4-over-ipv6 dra= ft is a general-purpose document, not specifically for lightweight 4over6. = So I recommended to the authors that they address this use case in a sepa= rate document, since this document was quite far along in the publication p= rocess when the address sharing issue came up. But of course this recommendation is just my personal recommendation=97if t= he working group would prefer to fold the address pool work into this docum= ent, I don't have any objection. From simon.perreault@viagenie.ca Thu Oct 18 08:53:36 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 093BB21F84F5 for ; Thu, 18 Oct 2012 08:53:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 ueJTGXWaHalE for ; Thu, 18 Oct 2012 08:53:35 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4D3EC21F84E6 for ; Thu, 18 Oct 2012 08:53:35 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:5c48:f469:9b94:d841]) by jazz.viagenie.ca (Postfix) with ESMTPSA id BF04A41630; Thu, 18 Oct 2012 11:53:34 -0400 (EDT) Message-ID: <508025FE.7070607@viagenie.ca> Date: Thu, 18 Oct 2012 11:53:34 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121009 Thunderbird/16.0 MIME-Version: 1.0 To: Ted Lemon References: <4B380728-0A9D-4B98-85C8-A723667C2676@nominum.com> <50800ECC.8060608@viagenie.ca> <5E8961DA-7D45-433C-A73F-FC6D1C230E67@nominum.com> <508021B6.2060906@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "" Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv4-over-ipv6 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, 18 Oct 2012 15:53:36 -0000 Le 2012-10-18 11:44, Ted Lemon a écrit : > On Oct 18, 2012, at 11:35 AM, Simon Perreault > wrote: >> The message would indeed go down the tunnel to the server. But >> remember that the CPE only has a partial IPv4 address on that >> tunnel interface. Messages sent from the server to the CPE's IPv4 >> address at port 68 will reach the CPE whose port range includes 68, >> not necessarily the CPE that sent the request. The result is that >> messages from client to server will work, but the reply will be >> lost. > > Ah, I see. You are talking about lightweight 4over6. Right. Sorry for not realizing that my issue was specific to LW4o6. > This is > indeed a problem, but only when address sharing is in use. The > dhcpv4-over-ipv6 draft is a general-purpose document, not > specifically for lightweight 4over6. So I recommended to the > authors that they address this use case in a separate document, since > this document was quite far along in the publication process when the > address sharing issue came up. Makes sense to me. But I would still appreciate if a paragraph was added to explain what happens to unicast messages. Namely, that an LCRA will not see them, and that they will take the regular IPv4 path. In addition, the draft should say that an HCRA MUST NOT convert unicast messages to IPv6, the reason being that you want LCRA and HCRA to exhibit similar behaviour. Thanks, Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From internet-drafts@ietf.org Thu Oct 18 09:00:25 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20C7221F882F; Thu, 18 Oct 2012 09:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 Y4GSUW-6r2Hs; Thu, 18 Oct 2012 09:00:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66FAC21F87FB; Thu, 18 Oct 2012 09:00:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121018160024.22292.50596.idtracker@ietfa.amsl.com> Date: Thu, 18 Oct 2012 09:00:24 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-03.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 16:00:25 -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 Group = of the IETF. Title : Client Link-layer Address Option in DHCPv6 Author(s) : Gaurav Halwasia Shwetha Bhandari Wojciech Dec Filename : draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-03.txt Pages : 6 Date : 2012-10-18 Abstract: This document specifies the format and mechanism that is to be used for encoding client link-layer address in DHCPv6 relay forward messages by defining a new DHCPv6 Client Link-layer Address option. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-client-link-layer-ad= dr-opt There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt= -03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-dhcpv6-client-link-layer-= addr-opt-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Ted.Lemon@nominum.com Thu Oct 18 09:12:32 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F6F621F8484 for ; Thu, 18 Oct 2012 09:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.491 X-Spam-Level: X-Spam-Status: No, score=-106.491 tagged_above=-999 required=5 tests=[AWL=0.108, 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 Uen9-lsoR+K9 for ; Thu, 18 Oct 2012 09:12:31 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id 8419C21F842D for ; Thu, 18 Oct 2012 09:12:31 -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 DSNKUIAqb1l182/kBiUMCAgy8AkHEDqMlJ8I@postini.com; Thu, 18 Oct 2012 09:12:31 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 A497F1B8344 for ; Thu, 18 Oct 2012 09:12:30 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 9AA9419005C for ; Thu, 18 Oct 2012 09:12:30 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Thu, 18 Oct 2012 09:12:30 -0700 From: Ted Lemon To: dhc WG Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt Thread-Index: Ac2X8ddMOw/OIH/tQHCVi0DiBXN4ZAVjzfUAAAE/LwA= Date: Thu, 18 Oct 2012 16:12:30 +0000 Message-ID: References: <7809F7E0-1EFD-491F-84AB-0F6DE8685927@nominum.com> In-Reply-To: <7809F7E0-1EFD-491F-84AB-0F6DE8685927@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <939FEDA80F5AA34FA7E3948724E84BF9@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 16:12:32 -0000 On Oct 18, 2012, at 11:36 AM, Ted Lemon wrote: > Well here it is, October 5, and it's time to evaluate consensus. Oh wai= t, it's October 18. But anyway, there were about ten participants in favo= r of advancing, and none opposed. Two participants, Bernie and Tim, had s= uggestions to clarify the text. Could the authors please sync up with Tim= and Bernie to get those fixes in and then post an updated document? Once= we have the updated doc, I will submit a shepherd doc to the IESG. The authors just submitted a new version which includes the change that Tim= requested. On reviewing the correspondence, I realized that Bernie and B= ud eventually agreed that no change was required, and that was confirmed i= n some private email from Guarav just now. So I'll be writing up a shephe= rd doc and sending it along. Thanks, everyone! (Tim, if I'm mistaken, there's still time for you to object! :) From otroan@employees.org Fri Oct 19 01:29:19 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31D6321F86E2 for ; Fri, 19 Oct 2012 01:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.26 X-Spam-Level: X-Spam-Status: No, score=-10.26 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 hfK1zfr7b9TI for ; Fri, 19 Oct 2012 01:29:18 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id D018921F8786 for ; Fri, 19 Oct 2012 01:29:09 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAHwOgVCQ/khL/2dsb2JhbABFwF2BCIIgAQEBAwESAQpcBQsLRlcGLgeHXAadNaAjkTpgA6Q0gWuCcQ X-IronPort-AV: E=Sophos;i="4.80,612,1344211200"; d="scan'208,217";a="77589976" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 19 Oct 2012 08:29:08 +0000 Received: from dhcp-lys01-vla250-10-147-112-212.cisco.com (dhcp-lys01-vla250-10-147-112-212.cisco.com [10.147.112.212]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9J8T7T3010549 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 19 Oct 2012 08:29:08 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_EB639BF9-A21A-4102-B270-417843081988" Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Fri, 19 Oct 2012 10:29:07 +0200 Message-Id: <35B57831-F31C-40D9-A34A-9469261F3636@employees.org> References: <9D3C0AC1-D5B1-4C25-AC47-4D08E3252D54@nominum.com> <50800059.3030503@viagenie.ca> <4E18E4F4-7E60-41F7-8700-83EF2CF1D4A4@employees.org> <219448E3-6A90-411D-A430-EDE011E5E75E@nominum.com> <50F411F4-D3C5-4CED-B9BD-5E552C61C5EE@employees.org> To: Qiong X-Mailer: Apple Mail (2.1498) Cc: sunqi , "" , Ted Lemon Subject: Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-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, 19 Oct 2012 08:29:19 -0000 --Apple-Mail=_EB639BF9-A21A-4102-B270-417843081988 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > indeed. The contiguous port mask is one example of MAP algorithm. But = we hope to simplify it from both implementation and operational point of = view, by removing all these parameters and algorithms. Contiguous = port-set using port mask is all we need, so we do not need anything = more.=20 I don't think we'll get anywhere with each of us claiming that "our" = algorithm is simpler than yours. it might be that the formal text in the MAP draft confuses the matter = unduly. let me try and explain again. MAP is based on the very simple idea of = describing a port range as a port prefix. for example I give you the port prefix 10.0/8, if we want to use the = same notation as we do for IP prefixes. 10/8 is 256 ports, in the range from 2560 - 2815. 0 8 15 +---------------+----------+--------------------------+ | Port Prefix / PSID | Port range | +---------------+----------+--------------------------+ for this you need two parameters, port prefix and port prefix length. = that is the simplest scheme that anyone has proposed as far as I know. do you agree? then the _only_ thing MAP does that is different from the above, is to = introduce one more configuration parameter, the offset. so that instead of it being purely a port _prefix_, the PSID can be a = port _infix_ or port _post-fix_. represented something like this: 0 8 15 +---------------+----------+--------------------------+ | Port range | PSID | Port range | +---------------+----------+--------------------------+ the problem with the port prefix (offset=3D0) in the top figure for the = use as embedded address bits, is that when the PSID is 0 then you'll end = up giving the system ports to a user. that would typically not be what = you want, and recommending an offset =3D 4, and the first port range > = 0, effectively excludes the system ports. for the case where you create = DHCP binding state per customer, you can just make sure to never assign = PSID =3D 0, so in your case you can of course use offset=3D0 are you still with me? > And besides, what we need is a DHCPv4 option, not DHCPv6. why? that's certainly not the only solution. given that you need a = DHCPv6 option to provision your IPv4 DHCP server. plus a lot of new = complex IPv4 DHCP machinery...? there is already a DHCPv6 option in process of being standardised. you = already depend on options from DHCPv6. why not reuse those existing = protocol mechanisms?=20 what I would suggest: - you merge with / ensure you have your requirements fulfilled by draft-ietf-softwire-map-dhcp-01 - rewrite LW4over6 / Public 4over6 to use DHCPv6 for complete = provisioning, using draft-ietf-softwire-map-dhcp cheers, Ole= --Apple-Mail=_EB639BF9-A21A-4102-B270-417843081988 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
indeed. The contiguous port mask is one example of = MAP algorithm. But we hope to simplify it from both implementation and = operational point of view, by removing all these parameters and = algorithms. Contiguous port-set using port mask is all we need, so we do = not need anything more. 

I = don't think we'll get anywhere with each of us claiming that "our" = algorithm is simpler than yours.
it might be that the formal text in the MAP draft confuses the = matter unduly.

let me try and = explain again. MAP is based on the very simple idea of describing a port = range as a port prefix.
for = example I give you the port prefix 10.0/8, if we want to use the same = notation as we do for IP prefixes.
10/8 is 256 ports, in the range from 2560 - = 2815.

  =  0                   =        8             =             15
  =  +---------------+----------+--------------------------+
=
   | Port Prefix / PSID   =     |       Port range       =   |
  =  +---------------+----------+--------------------------+
=

for this you need two parameters, port prefix and = port prefix length. that is the simplest scheme that anyone has proposed = as far as I know.
do you = agree?

then the _only_ = thing MAP does that is different from the above, is to introduce one = more configuration parameter, the offset.
so that instead of it being purely a port _prefix_, = the PSID can be a port _infix_ or port = _post-fix_.

represented = something like this:

  =  0                   =        8             =             15
  =  +---------------+----------+--------------------------+
=
   | Port range    | =         PSID       |  Port range =    |
  =  +---------------+----------+--------------------------+
=

the problem with the port prefix = (offset=3D0) in the top figure for the use as embedded address bits, is = that when the PSID is 0 then you'll end up giving the system ports to a = user. that would typically not be what you want, and recommending an = offset =3D 4, and the first port range > 0, effectively excludes the = system ports. for the case where you create DHCP binding state per = customer, you can just make sure to never assign PSID =3D 0, so in your = case you can of course use offset=3D0

are you still with me?

And besides, what we need is a = DHCPv4 option, not = DHCPv6.

why? that's certainly = not the only solution. given that you need a DHCPv6 option to provision = your IPv4 DHCP server. plus a lot of new complex IPv4 DHCP = machinery...?
there is already a DHCPv6 option in process of = being standardised. you already depend on options from DHCPv6. why not = reuse those existing protocol = mechanisms? 

what I would = suggest:
  - you merge with / ensure you have your = requirements fulfilled by
  =   draft-ietf-softwire-map-dhcp-01
  - rewrite = LW4over6 / Public 4over6 to use DHCPv6 for complete provisioning, using = draft-ietf-softwire-map-dhcp

cheers,
Ol= e
= --Apple-Mail=_EB639BF9-A21A-4102-B270-417843081988-- From mohamed.boucadair@orange.com Fri Oct 19 02:38:43 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C71721F8461 for ; Fri, 19 Oct 2012 02:38:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.985 X-Spam-Level: X-Spam-Status: No, score=-1.985 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, UNPARSEABLE_RELAY=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 uY3LQEhf7X72 for ; Fri, 19 Oct 2012 02:38:42 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 46EE621F8484 for ; Fri, 19 Oct 2012 02:38:42 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id E860926407A; Fri, 19 Oct 2012 11:38:40 +0200 (CEST) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id C4A6723804B; Fri, 19 Oct 2012 11:38:40 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Fri, 19 Oct 2012 11:38:40 +0200 From: To: =?iso-8859-1?Q?Ole_Tr=F8an?= , Qiong Date: Fri, 19 Oct 2012 11:38:38 +0200 Thread-Topic: [dhcwg] Call for adoption: draft-sun-dhc-port-set-option Thread-Index: Ac2t09iW17DGBI+gSniGWDI2MOef2AABmcrQ Message-ID: <94C682931C08B048B7A8645303FDC9F36E6556BD44@PUEXCB1B.nanterre.francetelecom.fr> References: <9D3C0AC1-D5B1-4C25-AC47-4D08E3252D54@nominum.com> <50800059.3030503@viagenie.ca> <4E18E4F4-7E60-41F7-8700-83EF2CF1D4A4@employees.org> <219448E3-6A90-411D-A430-EDE011E5E75E@nominum.com> <50F411F4-D3C5-4CED-B9BD-5E552C61C5EE@employees.org> <35B57831-F31C-40D9-A34A-9469261F3636@employees.org> In-Reply-To: <35B57831-F31C-40D9-A34A-9469261F3636@employees.org> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36E6556BD44PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.19.82415 Cc: sunqi , "" , Ted Lemon Subject: Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-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, 19 Oct 2012 09:38:43 -0000 --_000_94C682931C08B048B7A8645303FDC9F36E6556BD44PUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Ole, Please see inline. Cheers, Med ________________________________ De : dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] De la part de O= le Tr=F8an Envoy=E9 : vendredi 19 octobre 2012 10:29 =C0 : Qiong Cc : sunqi; ; Ted Lemon Objet : Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-option And besides, what we need is a DHCPv4 option, not DHCPv6. why? that's certainly not the only solution. given that you need a DHCPv6 o= ption to provision your IPv4 DHCP server. plus a lot of new complex IPv4 DH= CP machinery...? [Med] IMO the DHCPv6 option to configure the IPv4 DHCP server is not mandat= ory. The SI can assume its SC being its DHCPv4 server. there is already a DHCPv6 option in process of being standardised. you alre= ady depend on options from DHCPv6. why not reuse those existing protocol me= chanisms? [Med] This is a good point. We discussed it (i.e., include IPv4 address as = an IPv4-mapped IPv6 address) and even documented it here: http://tools.ietf.org/html/draft-cui-softwire-b4-translated-ds-lite-08#appe= ndix-A. But this was abandoned because we was told it is easy to manage tra= nsition-specific codes in DHCPv4 rather than DHCPv6. I don't remember well = the details but it is something related to the exit strategy for these spec= ific codes at the client side. what I would suggest: - you merge with / ensure you have your requirements fulfilled by draft-ietf-softwire-map-dhcp-01 - rewrite LW4over6 / Public 4over6 to use DHCPv6 for complete provisionin= g, using draft-ietf-softwire-map-dhcp [Med] Given what I understood to be the position of the DHC WG, a DHCPv4 op= tion is needed for lw4over6. cheers, Ole --_000_94C682931C08B048B7A8645303FDC9F36E6556BD44PUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear Ole,
 
Please see inline.
Cheers,
Med

De : dhcwg-bounces@ietf.org=20 [mailto:dhcwg-bounces@ietf.org] De la part de Ole=20 Tr=F8an
Envoy=E9 : vendredi 19 octobre 2012=20 10:29
=C0 : Qiong
Cc : sunqi;=20 <dhcwg@ietf.org>; Ted Lemon
Objet : Re: [dhcwg] Call= for=20 adoption: draft-sun-dhc-port-set-option


And besides, what we= need=20 is a DHCPv4 option, not DHCPv6.

why? that's certainly not the only solution. given that you need a D= HCPv6=20 option to provision your IPv4 DHCP server. plus a lot of new complex IPv4= DHCP=20 machinery...?
[Med] IMO the DHCPv6 option to configure the IP= v4 DHCP=20 server is not mandatory. The SI can assume its SC being its DHCPv4=20 server.
 
there is already a DHCPv6 option in process of being standardised. y= ou=20 already depend on options from DHCPv6. why not reuse those existing proto= col=20 mechanisms? 
[Med] This is a good point. We=20 discussed it (i.e., include IPv4 address as an IPv4-mapped IPv6= =20 address) and even documented it here:
http://tools.ietf.org/html/draft-cui-softwire-b4-translat= ed-ds-lite-08#appendix-A.=20 But this was abandoned because we was told it is eas= y to=20 manage transition-specific codes in DHCPv4 rather than DHCPv6. I don't=20 remember well the details but it is something related to the exit=20 strategy for these specific codes at the client side.
<= /DIV>
what I would suggest:
  - you merge with / ensure you have your requirements fulfille= d=20 by
    draft-ietf-softwire-map-dhcp-01
  - rewrite LW4over6 / Public 4over6 to use DHCPv6 for complete= =20 provisioning, using draft-ietf-softwire-map-dhcp
[Med] Given what I understood to be=20 the position of the DHC WG, a DHCPv4 option is needed for= =20 lw4over6. 

cheers,
Ole
--_000_94C682931C08B048B7A8645303FDC9F36E6556BD44PUEXCB1Bnante_-- From sunqi.thu@gmail.com Fri Oct 19 02:50:27 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5059721F869A for ; Fri, 19 Oct 2012 02:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.348 X-Spam-Level: X-Spam-Status: No, score=-3.348 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 SaH-PtCiq63L for ; Fri, 19 Oct 2012 02:50:26 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8C67521F8673 for ; Fri, 19 Oct 2012 02:50:25 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id s14so202659qcg.31 for ; Fri, 19 Oct 2012 02:50:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pBhlIxxjaOr1lBVdWNtbOZbbJm9lnqk78uYAO7ZZ7pI=; b=N9sAtzl1VfkCQUEArmbukKs4dOU/j42UZRf6VmgLoxytyyc0VYSfYNa6gKnWlj4jH+ yxL3n7kcM5ZRJPfCcuj6fY0jriZwJEvGvVk4pGayo3fvXFTvw0ifL0Qtwsqydv7C2tz+ r26EIkVZ3wU+eVSNv/ymzHeQuRf/8cz+T/I2ygtXDe6ieUOA/jGHFqYi6zdVDkRwFHhl r8vI6zgEMcJxUi8o+HtJ1XMyPKQo+FJTMA4jpdbjSCEqrsz9LVyXq8KUC3AKBeIxHQ7Y bqQT1AjU/NnwrYhMc5pSNto2mYy/6NmMHC69xb9ThuQD5a0v5L4T4Zfft/2jZjiB7zD9 iJYA== MIME-Version: 1.0 Received: by 10.224.95.196 with SMTP id e4mr436042qan.88.1350640225120; Fri, 19 Oct 2012 02:50:25 -0700 (PDT) Received: by 10.49.50.105 with HTTP; Fri, 19 Oct 2012 02:50:25 -0700 (PDT) In-Reply-To: <35B57831-F31C-40D9-A34A-9469261F3636@employees.org> References: <9D3C0AC1-D5B1-4C25-AC47-4D08E3252D54@nominum.com> <50800059.3030503@viagenie.ca> <4E18E4F4-7E60-41F7-8700-83EF2CF1D4A4@employees.org> <219448E3-6A90-411D-A430-EDE011E5E75E@nominum.com> <50F411F4-D3C5-4CED-B9BD-5E552C61C5EE@employees.org> <35B57831-F31C-40D9-A34A-9469261F3636@employees.org> Date: Fri, 19 Oct 2012 17:50:25 +0800 Message-ID: From: Qi Sun To: =?ISO-8859-1?Q?Ole_Tr=F8an?= Content-Type: multipart/alternative; boundary=20cf3063e355d6731904cc666e36 Cc: sunqi , "" , Ted Lemon Subject: Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-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, 19 Oct 2012 09:50:27 -0000 --20cf3063e355d6731904cc666e36 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Ole, Inline please. BR, Qi On Fri, Oct 19, 2012 at 4:29 PM, Ole Tr=F8an wrote: > indeed. The contiguous port mask is one example of MAP algorithm. But we > hope to simplify it from both implementation and operational point of vie= w, > by removing all these parameters and algorithms. Contiguous port-set usin= g > port mask is all we need, so we do not need anything more. > > > I don't think we'll get anywhere with each of us claiming that "our" > algorithm is simpler than yours. > it might be that the formal text in the MAP draft confuses the matter > unduly. > > let me try and explain again. MAP is based on the very simple idea of > describing a port range as a port prefix. > for example I give you the port prefix 10.0/8, if we want to use the same > notation as we do for IP prefixes. > 10/8 is 256 ports, in the range from 2560 - 2815. > > 0 8 15 > +---------------+----------+--------------------------+ > | Port Prefix / PSID | Port range | > +---------------+----------+--------------------------+ > > for this you need two parameters, port prefix and port prefix length. tha= t > is the simplest scheme that anyone has proposed as far as I know. > do you agree? > [Qi] This is what we do in draft-sun-*. Just need the port prefix and port prefix length to allocate one contiguous port-set. No other specific paras are needed. > > then the _only_ thing MAP does that is different from the above, is to > introduce one more configuration parameter, the offset. > so that instead of it being purely a port _prefix_, the PSID can be a por= t > _infix_ or port _post-fix_. > > represented something like this: > > 0 8 15 > +---------------+----------+--------------------------+ > | Port range | PSID | Port range | > +---------------+----------+--------------------------+ > > the problem with the port prefix (offset=3D0) in the top figure for the u= se > as embedded address bits, is that when the PSID is 0 then you'll end up > giving the system ports to a user. that would typically not be what you > want, and recommending an offset =3D 4, and the first port range > 0, > effectively excludes the system ports. for the case where you create DHCP > binding state per customer, you can just make sure to never assign PSID = =3D > 0, so in your case you can of course use offset=3D0 > > are you still with me? > > And besides, what we need is a DHCPv4 option, not DHCPv6. > > > why? that's certainly not the only solution. given that you need a DHCPv6 > option to provision your IPv4 DHCP server. plus a lot of new complex IPv4 > DHCP machinery...? > there is already a DHCPv6 option in process of being standardised. you > already depend on options from DHCPv6. why not reuse those existing > protocol mechanisms? > > what I would suggest: > - you merge with / ensure you have your requirements fulfilled by > draft-ietf-softwire-map-dhcp-01 > - rewrite LW4over6 / Public 4over6 to use DHCPv6 for complete > provisioning, using draft-ietf-softwire-map-dhcp > > cheers, > Ole > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > > --20cf3063e355d6731904cc666e36 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Ole,

Inline please.

BR,
Qi

On Fri, Oct 19, 2012 at 4:29 PM,= Ole Tr=F8an <otroan@employees.org> wrote:
indeed. The = contiguous port mask is one example of MAP algorithm. But we hope to simpli= fy it from both implementation and operational point=A0of view, by removing= all these parameters and algorithms. Contiguous port-set using port mask i= s all we need, so we do not need anything more.=A0

=
I don't think we'll get anywhere wi= th each of us claiming that "our" algorithm is simpler than yours= .
it might be that the formal text in the MAP= draft confuses the matter unduly.

let me try and explain= again. MAP is based on the very simple idea of describing a port range as = a port prefix.
for example I give you the port prefix 10.0= /8, if we want to use the same notation as we do for IP prefixes.
10/8 is 256 ports, in the range from 256= 0 - 2815.

=A0 =A00 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A08 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 15
=A0 =A0+---------------+----------+--------------------= ------+
=A0 =A0| Port Prefix / PSID =A0 =A0 =A0 | = =A0 =A0 =A0 Port range =A0 =A0 =A0 =A0 |
=A0 =A0+---------------+----------+--------------------------+

for this you need two pa= rameters, port prefix and port prefix length. that is the simplest scheme t= hat anyone has proposed as far as I know.
do you agree?

[Qi] This is what we do in draft-sun= -*. Just need the port prefix and port prefix length to allocate one contig= uous port-set. No other specific paras are needed.
=A0

then the _only_ thing MAP does th= at is different from the above, is to introduce one more configuration para= meter, the offset.
so that instead of it being purely a port _= prefix_, the PSID can be a port _infix_ or port _post-fix_.

represented something like this:

=A0 =A00 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A08 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 15
=A0 =A0+---------------+----------+--------------------= ------+
=A0 =A0| Port range =A0 =A0| =A0 =A0 =A0 = =A0 PSID =A0 =A0 =A0 | =A0Port range =A0 =A0|
=A0 =A0+---------------+----------+-----------------------= ---+

the pro= blem with the port prefix (offset=3D0) in the top figure for the use as emb= edded address bits, is that when the PSID is 0 then you'll end up givin= g the system ports to a user. that would typically not be what you want, an= d recommending an offset =3D 4, and the first port range > 0, effectivel= y excludes the system ports. for the case where you create DHCP binding sta= te per customer, you can just make sure to never assign PSID =3D 0, so in y= our case you can of course use offset=3D0

are you still with me?

<= blockquote type=3D"cite">And besides, what we ne= ed is a DHCPv4 option, not DHCPv6.

why? that's certainly not= the only solution. given that you need a DHCPv6 option to provision your I= Pv4 DHCP server. plus a lot of new complex IPv4 DHCP machinery...?
there is already a DHCPv6 option in process of being standardised. you= already depend on options from DHCPv6. why not reuse those existing protoc= ol mechanisms?=A0

what I would suggest:
=A0 - you merge with / ensure you have your requirements fulfilled by
=
=A0 =A0=A0draft-ietf-softwire-map-dhcp-01
=A0 - rewrite LW4o= ver6 / Public 4over6 to use DHCPv6 for complete provisioning, using draft-i= etf-softwire-map-dhcp

cheers,
Ole

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


--20cf3063e355d6731904cc666e36-- From otroan@employees.org Fri Oct 19 03:34:42 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C56E921F860A for ; Fri, 19 Oct 2012 03:34:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.262 X-Spam-Level: X-Spam-Status: No, score=-10.262 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 zetTyVyMiTxh for ; Fri, 19 Oct 2012 03:34:42 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id A337E21F85AF for ; Fri, 19 Oct 2012 03:34:41 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak4JAJErgVCQ/khN/2dsb2JhbABFv1MEBIEFgQiCIQEBBBIBClwQC0ZXBi4Hh2KdRaArkWdgA6Q8gWuCcQ X-IronPort-AV: E=Sophos;i="4.80,612,1344211200"; d="scan'208";a="8940404" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-4.cisco.com with ESMTP; 19 Oct 2012 10:34:40 +0000 Received: from dhcp-lys01-vla250-10-147-112-212.cisco.com (dhcp-lys01-vla250-10-147-112-212.cisco.com [10.147.112.212]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q9JAYdhd012437 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 19 Oct 2012 10:34:40 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Fri, 19 Oct 2012 12:34:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9D3C0AC1-D5B1-4C25-AC47-4D08E3252D54@nominum.com> <50800059.3030503@viagenie.ca> <4E18E4F4-7E60-41F7-8700-83EF2CF1D4A4@employees.org> <219448E3-6A90-411D-A430-EDE011E5E75E@nominum.com> <50F411F4-D3C5-4CED-B9BD-5E552C61C5EE@employees.org> <35B57831-F31C-40D9-A34A-9469261F3636@employees.org> To: Qi Sun X-Mailer: Apple Mail (2.1498) Cc: sunqi , "" , Ted Lemon Subject: Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-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, 19 Oct 2012 10:34:42 -0000 Qi, > [Qi] This is what we do in draft-sun-*. Just need the port prefix and = port prefix length to allocate one contiguous port-set. No other = specific paras are needed. there is a port mapping algorithm and DHCP option as working group = adopted drafts already, that has 3 parameters; port prefix, prefix = length and offset. you think it is necessary for the industry to have a = separate document to describe the exact same subset of the option above, = but with 2 parameters; port prefix and prefix length? sigh. creating an RFC for _every_ possible solution and option isn't = standardisation. cheers, Ole= From mohamed.boucadair@orange.com Fri Oct 19 04:19:12 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DAE321F852B for ; Fri, 19 Oct 2012 04:19:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.985 X-Spam-Level: X-Spam-Status: No, score=-1.985 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, UNPARSEABLE_RELAY=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 tGAwwpEcl68F for ; Fri, 19 Oct 2012 04:19:11 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 80DAC21F846F for ; Fri, 19 Oct 2012 04:19:11 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id A7DFA18C111; Fri, 19 Oct 2012 13:19:09 +0200 (CEST) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 8067F23806B; Fri, 19 Oct 2012 13:19:09 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Fri, 19 Oct 2012 13:19:09 +0200 From: To: =?iso-8859-1?Q?Ole_Tr=F8an?= , Qi Sun Date: Fri, 19 Oct 2012 13:19:07 +0200 Thread-Topic: [dhcwg] Call for adoption: draft-sun-dhc-port-set-option Thread-Index: Ac2t5VzBildh6/qhTweVI1Tf6+Z3SAABHMlQ Message-ID: <94C682931C08B048B7A8645303FDC9F36E6556BDC0@PUEXCB1B.nanterre.francetelecom.fr> References: <9D3C0AC1-D5B1-4C25-AC47-4D08E3252D54@nominum.com> <50800059.3030503@viagenie.ca> <4E18E4F4-7E60-41F7-8700-83EF2CF1D4A4@employees.org> <219448E3-6A90-411D-A430-EDE011E5E75E@nominum.com> <50F411F4-D3C5-4CED-B9BD-5E552C61C5EE@employees.org> <35B57831-F31C-40D9-A34A-9469261F3636@employees.org> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.19.115414 Cc: sunqi , "" , Ted Lemon Subject: Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-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, 19 Oct 2012 11:19:12 -0000 Ole, As a reminder, this is a call for adoption and not a WGLC. The encoding can be changed to reflect the WG consensus but we are not ther= e at this stage. The main point is the port mask is compliant with it is do= cumented in the map document. So, there are already synergies between lw4ov= er6 and map efforts. Is there a need to import all map specific parameters = into draft-sun-dhc-port-set-option? IMO, this is a discussion point we can = work on when we advance in the lw4over6 specification. draft-sub-* is defining a DHCPv4 option not a DHCPv6 one. As such your prop= osal does not work. I already explained why we abandoned the DHCPv6 track f= or this work. Cheers, Med =20 >-----Message d'origine----- >De : dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] De=20 >la part de Ole Tr=F8an >Envoy=E9 : vendredi 19 octobre 2012 12:35 >=C0 : Qi Sun >Cc : sunqi; ; Ted Lemon >Objet : Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-option > >Qi, > >> [Qi] This is what we do in draft-sun-*. Just need the port=20 >prefix and port prefix length to allocate one contiguous=20 >port-set. No other specific paras are needed. > >there is a port mapping algorithm and DHCP option as working=20 >group adopted drafts already, that has 3 parameters; port=20 >prefix, prefix length and offset. you think it is necessary=20 >for the industry to have a separate document to describe the=20 >exact same subset of the option above, but with 2 parameters;=20 >port prefix and prefix length? > >sigh. creating an RFC for _every_ possible solution and option=20 >isn't standardisation. > >cheers, >Ole >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www.ietf.org/mailman/listinfo/dhcwg >= From sunqi.thu@gmail.com Fri Oct 19 04:19:24 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 876F321F8648 for ; Fri, 19 Oct 2012 04:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.336 X-Spam-Level: X-Spam-Status: No, score=-3.336 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 gOfTHnvuRX9T for ; Fri, 19 Oct 2012 04:19:23 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 763B721F863F for ; Fri, 19 Oct 2012 04:19:23 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id s14so249957qcg.31 for ; Fri, 19 Oct 2012 04:19:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UZ8R3sjJh+3pqIQb8J+hawUGh1k7fmO/CmFhVddApPM=; b=h6gK7+hg3LCZccEXQWKsTMt+v4FgagovF2AWX8vL8SPCS2QEPh5OeiAzRHtlCQboI1 XujZJGLrDtfSjaasOsz/7Y+8uqx3b5RM592B66strvtZoSpSu9frONwEPS3dR4ttoeKF 3ixEdzVXW5KHNHJ6V+RUL+9tvmI8atcvoDcQkX+rAD4eJMXchLbzyp3kmB+SX9iH13Fa wyOSsgx8AjJoR7yZPOVpi6qqrGehjT3aVi2A6Mz/eYXpGEP+d0ePCpiD8gB0Nia1mGrf i/QGrhQecDetbyVeaO+mUP1Q3f7UTca7+NwE202c1Cw4O5BJdF/ufmqCPHA8EiUoSmt6 OoQA== MIME-Version: 1.0 Received: by 10.229.179.193 with SMTP id br1mr106224qcb.41.1350645562880; Fri, 19 Oct 2012 04:19:22 -0700 (PDT) Received: by 10.49.50.105 with HTTP; Fri, 19 Oct 2012 04:19:22 -0700 (PDT) In-Reply-To: References: <9D3C0AC1-D5B1-4C25-AC47-4D08E3252D54@nominum.com> <50800059.3030503@viagenie.ca> <4E18E4F4-7E60-41F7-8700-83EF2CF1D4A4@employees.org> <219448E3-6A90-411D-A430-EDE011E5E75E@nominum.com> <50F411F4-D3C5-4CED-B9BD-5E552C61C5EE@employees.org> <35B57831-F31C-40D9-A34A-9469261F3636@employees.org> Date: Fri, 19 Oct 2012 19:19:22 +0800 Message-ID: From: Qi Sun To: =?ISO-8859-1?Q?Ole_Tr=F8an?= Content-Type: multipart/alternative; boundary=005045016576fe34ea04cc67ac4f Cc: sunqi , "" , Ted Lemon Subject: Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-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, 19 Oct 2012 11:19:24 -0000 --005045016576fe34ea04cc67ac4f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Ole, IMHO, you refer to a DHCPv6 option for allocating IPv4 address-related resources, right? I think Med's email has explained the reasons clearly. Qi On Fri, Oct 19, 2012 at 6:34 PM, Ole Tr=F8an wrote: > Qi, > > > [Qi] This is what we do in draft-sun-*. Just need the port prefix and > port prefix length to allocate one contiguous port-set. No other specific > paras are needed. > > there is a port mapping algorithm and DHCP option as working group adopte= d > drafts already, that has 3 parameters; port prefix, prefix length and > offset. you think it is necessary for the industry to have a separate > document to describe the exact same subset of the option above, but with = 2 > parameters; port prefix and prefix length? > > sigh. creating an RFC for _every_ possible solution and option isn't > standardisation. > > cheers, > Ole --005045016576fe34ea04cc67ac4f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Ole,

IMHO, you refer to a DHCPv6 option for allocatin= g IPv4 address-related resources, right? I think Med's email has explai= ned the reasons clearly.

Qi

On Fri, Oct 19, 2012 at 6:34 PM, Ole Tr=F8an <otroan@employees.org= > wrote:
Qi,

> [Qi] This is what we do in draft-sun-*. Just need the port prefix and = port prefix length to allocate one contiguous port-set. No other specific p= aras are needed.

there is a port mapping algorithm and DHCP option as working group ad= opted drafts already, that has 3 parameters; port prefix, prefix length and= offset. you think it is necessary for the industry to have a separate docu= ment to describe the exact same subset of the option above, but with 2 para= meters; port prefix and prefix length?

sigh. creating an RFC for _every_ possible solution and option isn't st= andardisation.

cheers,
Ole

--005045016576fe34ea04cc67ac4f-- From otroan@employees.org Fri Oct 19 05:32:24 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B652E21F85F7 for ; Fri, 19 Oct 2012 05:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.265 X-Spam-Level: X-Spam-Status: No, score=-10.265 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 cuyhIsscC1cn for ; Fri, 19 Oct 2012 05:32:24 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 02B9721F8480 for ; Fri, 19 Oct 2012 05:32:23 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAINHgVCQ/khM/2dsb2JhbABFwGGBCIIgAQEBAwESAQpXBQULC0ZXBi4Hh1wGnHWgL48kgkNgA6Q8gWuCcQ X-IronPort-AV: E=Sophos;i="4.80,612,1344211200"; d="scan'208";a="145521909" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 19 Oct 2012 12:32:21 +0000 Received: from dhcp-lys02-vla252-10-147-117-91.cisco.com (dhcp-lys02-vla252-10-147-117-91.cisco.com [10.147.117.91]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9JCWKr8004547 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 19 Oct 2012 12:32:20 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E6556BDC0@PUEXCB1B.nanterre.francetelecom.fr> Date: Fri, 19 Oct 2012 14:32:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6C44435A-4FDB-42D5-860D-89CAF1346C01@employees.org> References: <9D3C0AC1-D5B1-4C25-AC47-4D08E3252D54@nominum.com> <50800059.3030503@viagenie.ca> <4E18E4F4-7E60-41F7-8700-83EF2CF1D4A4@employees.org> <219448E3-6A90-411D-A430-EDE011E5E75E@nominum.com> <50F411F4-D3C5-4CED-B9BD-5E552C61C5EE@employees.org> <35B57831-F31C-40D9-A34A-9469261F3636@employees.org> <94C682931C08B048B7A8645303FDC9F36E6556BDC0@PUEXCB1B.nanterre.francetelecom.fr> To: X-Mailer: Apple Mail (2.1498) Cc: sunqi , "" , Ted Lemon Subject: Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-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, 19 Oct 2012 12:32:24 -0000 Med, > As a reminder, this is a call for adoption and not a WGLC. indeed. I think=20 a) it shouldn't be adopted without a "customer". i.e. a draft in = softwire b) it shouldn't be adopted because there is an existing solution = progressing in softwire for this already. > The encoding can be changed to reflect the WG consensus but we are not = there at this stage. The main point is the port mask is compliant with = it is documented in the map document. So, there are already synergies = between lw4over6 and map efforts. Is there a need to import all map = specific parameters into draft-sun-dhc-port-set-option? IMO, this is a = discussion point we can work on when we advance in the lw4over6 = specification. >=20 > draft-sub-* is defining a DHCPv4 option not a DHCPv6 one. As such your = proposal does not work. I already explained why we abandoned the DHCPv6 = track for this work. given that the world has moved on and that we have already defined = options to provision IPv4 addresses and port sets in DHCPv6. do you = think the reasons for choosing DHCPv4 provisioning still applies? is = there any case where you want to use this and you do _not_ have DHCPv6 = available? e.g. A+P IPv4 tunneled in IPv4, VLANs etc? (and no, I'm not = suggesting someone should standardize any of those. ;-)) Best regards, Ole= From lear@cisco.com Fri Oct 19 05:42:31 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB00D21F8596 for ; Fri, 19 Oct 2012 05:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.416 X-Spam-Level: X-Spam-Status: No, score=-110.416 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 C-n2hnCe87GX for ; Fri, 19 Oct 2012 05:42:30 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 231F921F8594 for ; Fri, 19 Oct 2012 05:42:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14281; q=dns/txt; s=iport; t=1350650550; x=1351860150; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=GdKXqko1WcDAzK+VDRRlMgdCbB7Ci49Ot3N2QIQ0Rz4=; b=X7NKob9pLsanJC3BAClTTCsAMs3CvF5uALk+hwA5OQJJBZUCWHIf75DZ GyfTb/uKeQuEKAQC7YuX/GHJRcZBOso9MgfkXEjRKKawnDWtdDZTeJeya EZ9cZh9ay6aM0qCjT6KGo5BSAKfbxtgDRQKhYAIXptMnRVruBlbsY/jRb I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As0FANxJgVCQ/khN/2dsb2JhbABFhhKFX7RxgQiCIAEBAQQBAQEPAQoGSwoBEAkCGAkWCAMCAgkDAgECARUfEQYNAQUCAQEXB4diC5xkjSGTCASLWIVdgRIDlW+OTYFrgnE X-IronPort-AV: E=Sophos;i="4.80,612,1344211200"; d="scan'208,217";a="77595711" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 19 Oct 2012 12:42:28 +0000 Received: from dhcp-10-55-81-70.cisco.com (dhcp-10-55-81-70.cisco.com [10.55.81.70]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q9JCgRSF006263 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Oct 2012 12:42:28 GMT Message-ID: <50814AB3.9070307@cisco.com> Date: Fri, 19 Oct 2012 14:42:27 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Qi Sun References: <9D3C0AC1-D5B1-4C25-AC47-4D08E3252D54@nominum.com> <50800059.3030503@viagenie.ca> <4E18E4F4-7E60-41F7-8700-83EF2CF1D4A4@employees.org> <219448E3-6A90-411D-A430-EDE011E5E75E@nominum.com> <50F411F4-D3C5-4CED-B9BD-5E552C61C5EE@employees.org> <35B57831-F31C-40D9-A34A-9469261F3636@employees.org> In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: multipart/alternative; boundary="------------030903060008050609070303" Cc: sunqi , "" , Ted Lemon Subject: Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-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, 19 Oct 2012 12:42:31 -0000 This is a multi-part message in MIME format. --------------030903060008050609070303 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit -1 for adoption. The work is substantially complete in softwires, and while overlap in some cases happens, it should happen for good reason. Ole has explained that the case you are attempting to cover is already covered by the softwires draft, and I haven't yet heard any serious argument for development of an IPv4 option. If either WG later decides that an IPv4 option IS required it should be based on the existing softwires work. Eliot On 10/19/12 11:50 AM, Qi Sun wrote: > Hi Ole, > > Inline please. > > BR, > Qi > > On Fri, Oct 19, 2012 at 4:29 PM, Ole Trøan > wrote: > >> indeed. The contiguous port mask is one example of MAP algorithm. >> But we hope to simplify it from both implementation and >> operational point of view, by removing all these parameters and >> algorithms. Contiguous port-set using port mask is all we need, >> so we do not need anything more. > > I don't think we'll get anywhere with each of us claiming that > "our" algorithm is simpler than yours. > it might be that the formal text in the MAP draft confuses the > matter unduly. > > let me try and explain again. MAP is based on the very simple idea > of describing a port range as a port prefix. > for example I give you the port prefix 10.0/8, if we want to use > the same notation as we do for IP prefixes. > 10/8 is 256 ports, in the range from 2560 - 2815. > > 0 8 15 > +---------------+----------+--------------------------+ > | Port Prefix / PSID | Port range | > +---------------+----------+--------------------------+ > > for this you need two parameters, port prefix and port prefix > length. that is the simplest scheme that anyone has proposed as > far as I know. > do you agree? > > > [Qi] This is what we do in draft-sun-*. Just need the port prefix and > port prefix length to allocate one contiguous port-set. No other > specific paras are needed. > > > > then the _only_ thing MAP does that is different from the above, > is to introduce one more configuration parameter, the offset. > so that instead of it being purely a port _prefix_, the PSID can > be a port _infix_ or port _post-fix_. > > represented something like this: > > 0 8 15 > +---------------+----------+--------------------------+ > | Port range | PSID | Port range | > +---------------+----------+--------------------------+ > > the problem with the port prefix (offset=0) in the top figure for > the use as embedded address bits, is that when the PSID is 0 then > you'll end up giving the system ports to a user. that would > typically not be what you want, and recommending an offset = 4, > and the first port range > 0, effectively excludes the system > ports. for the case where you create DHCP binding state per > customer, you can just make sure to never assign PSID = 0, so in > your case you can of course use offset=0 > > are you still with me? > >> And besides, what we need is a DHCPv4 option, not DHCPv6. > > why? that's certainly not the only solution. given that you need a > DHCPv6 option to provision your IPv4 DHCP server. plus a lot of > new complex IPv4 DHCP machinery...? > there is already a DHCPv6 option in process of being standardised. > you already depend on options from DHCPv6. why not reuse those > existing protocol mechanisms? > > what I would suggest: > - you merge with / ensure you have your requirements fulfilled by > draft-ietf-softwire-map-dhcp-01 > - rewrite LW4over6 / Public 4over6 to use DHCPv6 for complete > provisioning, using draft-ietf-softwire-map-dhcp > > cheers, > Ole > > _______________________________________________ > 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 --------------030903060008050609070303 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit -1 for adoption. 

The work is substantially complete in softwires, and while overlap in some cases happens, it should happen for good reason.  Ole has explained that the case you are attempting to cover is already covered by the softwires draft, and I haven't yet heard any serious argument for development of an IPv4 option.  If either WG later decides that an IPv4 option IS required it should be based on the existing softwires work.

Eliot


On 10/19/12 11:50 AM, Qi Sun wrote:
Hi Ole,

Inline please.

BR,
Qi

On Fri, Oct 19, 2012 at 4:29 PM, Ole Trøan <otroan@employees.org> wrote:
indeed. The contiguous port mask is one example of MAP algorithm. But we hope to simplify it from both implementation and operational point of view, by removing all these parameters and algorithms. Contiguous port-set using port mask is all we need, so we do not need anything more. 

I don't think we'll get anywhere with each of us claiming that "our" algorithm is simpler than yours.
it might be that the formal text in the MAP draft confuses the matter unduly.

let me try and explain again. MAP is based on the very simple idea of describing a port range as a port prefix.
for example I give you the port prefix 10.0/8, if we want to use the same notation as we do for IP prefixes.
10/8 is 256 ports, in the range from 2560 - 2815.

   0                          8                         15
   +---------------+----------+--------------------------+
   | Port Prefix / PSID       |       Port range         |
   +---------------+----------+--------------------------+

for this you need two parameters, port prefix and port prefix length. that is the simplest scheme that anyone has proposed as far as I know.
do you agree?

[Qi] This is what we do in draft-sun-*. Just need the port prefix and port prefix length to allocate one contiguous port-set. No other specific paras are needed.
 

then the _only_ thing MAP does that is different from the above, is to introduce one more configuration parameter, the offset.
so that instead of it being purely a port _prefix_, the PSID can be a port _infix_ or port _post-fix_.

represented something like this:

   0                          8                         15
   +---------------+----------+--------------------------+
   | Port range    |         PSID       |  Port range    |
   +---------------+----------+--------------------------+

the problem with the port prefix (offset=0) in the top figure for the use as embedded address bits, is that when the PSID is 0 then you'll end up giving the system ports to a user. that would typically not be what you want, and recommending an offset = 4, and the first port range > 0, effectively excludes the system ports. for the case where you create DHCP binding state per customer, you can just make sure to never assign PSID = 0, so in your case you can of course use offset=0

are you still with me?

And besides, what we need is a DHCPv4 option, not DHCPv6.

why? that's certainly not the only solution. given that you need a DHCPv6 option to provision your IPv4 DHCP server. plus a lot of new complex IPv4 DHCP machinery...?
there is already a DHCPv6 option in process of being standardised. you already depend on options from DHCPv6. why not reuse those existing protocol mechanisms? 

what I would suggest:
  - you merge with / ensure you have your requirements fulfilled by
    draft-ietf-softwire-map-dhcp-01
  - rewrite LW4over6 / Public 4over6 to use DHCPv6 for complete provisioning, using draft-ietf-softwire-map-dhcp

cheers,
Ole

_______________________________________________
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

--------------030903060008050609070303-- From mohamed.boucadair@orange.com Fri Oct 19 05:47:31 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B8DE21F84F1 for ; Fri, 19 Oct 2012 05:47:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.985 X-Spam-Level: X-Spam-Status: No, score=-1.985 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, UNPARSEABLE_RELAY=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 UgpR-0kyECvF for ; Fri, 19 Oct 2012 05:47:31 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id E90E121F84B3 for ; Fri, 19 Oct 2012 05:47:30 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 1148F3244DE; Fri, 19 Oct 2012 14:47:30 +0200 (CEST) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id E68E14C066; Fri, 19 Oct 2012 14:47:29 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Fri, 19 Oct 2012 14:47:29 +0200 From: To: =?iso-8859-1?Q?Ole_Tr=F8an?= Date: Fri, 19 Oct 2012 14:47:28 +0200 Thread-Topic: [dhcwg] Call for adoption: draft-sun-dhc-port-set-option Thread-Index: Ac2t9cuRbR8RsBvAT+mjUjpsL9hsdQAAIRjg Message-ID: <94C682931C08B048B7A8645303FDC9F36E6556BE52@PUEXCB1B.nanterre.francetelecom.fr> References: <9D3C0AC1-D5B1-4C25-AC47-4D08E3252D54@nominum.com> <50800059.3030503@viagenie.ca> <4E18E4F4-7E60-41F7-8700-83EF2CF1D4A4@employees.org> <219448E3-6A90-411D-A430-EDE011E5E75E@nominum.com> <50F411F4-D3C5-4CED-B9BD-5E552C61C5EE@employees.org> <35B57831-F31C-40D9-A34A-9469261F3636@employees.org> <94C682931C08B048B7A8645303FDC9F36E6556BDC0@PUEXCB1B.nanterre.francetelecom.fr> <6C44435A-4FDB-42D5-860D-89CAF1346C01@employees.org> In-Reply-To: <6C44435A-4FDB-42D5-860D-89CAF1346C01@employees.org> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.19.110315 Cc: sunqi , "" , Ted Lemon Subject: Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-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, 19 Oct 2012 12:47:31 -0000 Re-, Please see inline. Cheers, Med=20 >-----Message d'origine----- >De : Ole Tr=F8an [mailto:otroan@employees.org]=20 >Envoy=E9 : vendredi 19 octobre 2012 14:32 >=C0 : BOUCADAIR Mohamed OLNC/OLN >Cc : Qi Sun; sunqi; ; Ted Lemon >Objet : Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-option > >Med, > >> As a reminder, this is a call for adoption and not a WGLC. > >indeed. I think=20 > a) it shouldn't be adopted without a "customer". i.e. a draft=20 >in softwire Med: To be accurate, there is already a "customer" for it: RFC6346 (binding= table mode). From Ted.Lemon@nominum.com Fri Oct 19 07:18:30 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF41921F86C8 for ; Fri, 19 Oct 2012 07:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.344 X-Spam-Level: X-Spam-Status: No, score=-106.344 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 izq66yCFiNlw for ; Fri, 19 Oct 2012 07:18:30 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id B765921F86A0 for ; Fri, 19 Oct 2012 07:18:29 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKUIFhNekFjME2dsNwLluf/V3FVMtaf5i+@postini.com; Fri, 19 Oct 2012 07:18:29 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 9C2DA1B8357 for ; Fri, 19 Oct 2012 07:18:28 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 9045C19005C; Fri, 19 Oct 2012 07:18:28 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Fri, 19 Oct 2012 07:18:28 -0700 From: Ted Lemon To: =?iso-8859-1?Q?Ole_Tr=F8an?= Thread-Topic: [dhcwg] Call for adoption: draft-sun-dhc-port-set-option Thread-Index: AQHNput68Hhly3n5akOtNZsf4t9jOpe/NbeAgABWX4CAAARBgIAAAb6AgAABPwCAAAUAAIAAARwAgAAMdICAAAMNAIABJiyAgABhnAA= Date: Fri, 19 Oct 2012 14:18:28 +0000 Message-ID: <0403A628-C86D-49E6-8FF9-E60BC1511169@nominum.com> References: <9D3C0AC1-D5B1-4C25-AC47-4D08E3252D54@nominum.com> <50800059.3030503@viagenie.ca> <4E18E4F4-7E60-41F7-8700-83EF2CF1D4A4@employees.org> <219448E3-6A90-411D-A430-EDE011E5E75E@nominum.com> <50F411F4-D3C5-4CED-B9BD-5E552C61C5EE@employees.org> <35B57831-F31C-40D9-A34A-9469261F3636@employees.org> In-Reply-To: <35B57831-F31C-40D9-A34A-9469261F3636@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sunqi , "" Subject: Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-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, 19 Oct 2012 14:18:30 -0000 On Oct 19, 2012, at 4:29 AM, Ole Tr=F8an wrote: > what I would suggest: > - you merge with / ensure you have your requirements fulfilled by > draft-ietf-softwire-map-dhcp-01 > - rewrite LW4over6 / Public 4over6 to use DHCPv6 for complete provision= ing, using draft-ietf-softwire-map-dhcp Right, so the working group already concluded over a year ago that we weren= 't going to do this, because DHCPv6 servers don't allocate IPv4 addresses. = You claim that the DHCPv6 solution is simpler, but it's not, because it r= equires permanent changes to DHCPv6. DHCPv4 is a protocol that is becomin= g obsolete; using DHCPv4 to deliver IPv4 addresses for transition technolog= y is a big win, because the changes die with the protocol, and don't have t= o be carried forward forever. The only additional complexity to the DHCPv4-over-IPv6 solution is to allow= it to work in the non-port-range environment for unmodified DHCPv4 clients= . This is a conclusion that the DHC working group draw a long time ago. The= DHC working group adopted the DHCPv4-over-IPv6 work. That work is near c= ompletion. The call for adoption on this draft is not a referendum on the= question of whether we should do DHCPv4-over-IPv6. We are already doing = that. From Ted.Lemon@nominum.com Fri Oct 19 07:38:26 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C22BA21F845B for ; Fri, 19 Oct 2012 07:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.493 X-Spam-Level: X-Spam-Status: No, score=-106.493 tagged_above=-999 required=5 tests=[AWL=0.106, 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 1WXSPnRBy6+s for ; Fri, 19 Oct 2012 07:38:26 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id 1B7E921F8575 for ; Fri, 19 Oct 2012 07:38:25 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKUIFl4TCVes8v8xhm1bF+y2CcZ8XmwNE3@postini.com; Fri, 19 Oct 2012 07:38: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 12D7B1B8358 for ; Fri, 19 Oct 2012 07:38:25 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 02A8F19005C; Fri, 19 Oct 2012 07:38:25 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Fri, 19 Oct 2012 07:38:18 -0700 From: Ted Lemon To: Eliot Lear Thread-Topic: [dhcwg] Call for adoption: draft-sun-dhc-port-set-option Thread-Index: AQHNput68Hhly3n5akOtNZsf4t9jOpe/NbeAgABWX4CAAARBgIAAAb6AgAABPwCAAAUAAIAAARwAgAAMdICAAAMNAIABJiyAgAAWt4CAADARgIAAIF4A Date: Fri, 19 Oct 2012 14:38:19 +0000 Message-ID: <2D7C2D36-D308-4480-8858-9F5EF23EDC06@nominum.com> References: <9D3C0AC1-D5B1-4C25-AC47-4D08E3252D54@nominum.com> <50800059.3030503@viagenie.ca> <4E18E4F4-7E60-41F7-8700-83EF2CF1D4A4@employees.org> <219448E3-6A90-411D-A430-EDE011E5E75E@nominum.com> <50F411F4-D3C5-4CED-B9BD-5E552C61C5EE@employees.org> <35B57831-F31C-40D9-A34A-9469261F3636@employees.org> <50814AB3.9070307@cisco.com> In-Reply-To: <50814AB3.9070307@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sunqi , "" Subject: Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-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, 19 Oct 2012 14:38:26 -0000 On Oct 19, 2012, at 8:42 AM, Eliot Lear wrote: > The work is substantially complete in softwires, and while overlap in som= e cases happens, it should happen for good reason. Ole has explained that = the case you are attempting to cover is already covered by the softwires dr= aft, and I haven't yet heard any serious argument for development of an IPv= 4 option. If either WG later decides that an IPv4 option IS required it sh= ould be based on the existing softwires work. It's not really within softwires' bailiwick to decide how the DHCP protocol= will be extended. Ordinarily we would expect any such work to be done in= the DHC working group. And indeed quite some time ago people came from s= oftwires to talk about whether to use DHCPv4 or DHCPv6 to solve this proble= m, and the working group decided to use DHCPv4 and not DHCPv6, for reasons = I described in a separate message. So it may be that softwires has continued on in a different direction since= then, but the DHC working group has been working steadily on a solution in= volving DHCPv4, and it's a bit late to be telling us now that softwires has= decided to go against the DHC consensus and break DHCPv6. From lear@cisco.com Fri Oct 19 09:11:25 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AF4621F8764 for ; Fri, 19 Oct 2012 09:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.42 X-Spam-Level: X-Spam-Status: No, score=-110.42 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 i2WP7O-D8o81 for ; Fri, 19 Oct 2012 09:11:24 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id E639921F87D6 for ; Fri, 19 Oct 2012 09:11:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8160; q=dns/txt; s=iport; t=1350663084; x=1351872684; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=xg6BHiJSdxRNihj7UK72TbnUtrB50pPa+iSNTvIEWNw=; b=nAonuYmrfa2pD7qKmoMLcmo4Q9Nt4s829Qr4eS0TRytXbnWyboElJjag kW7sOBpxqlBO08nvCl6HPWmtUDU3BOb6roTm5HI4J98xBOtjW09zGp7Ow tSBo9MI4uuOpLbw4DVtGswMv6WQG71QAJ7lYlYcnOVLZWpGuKD4KVwFaL U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As0FANR6gVCQ/khN/2dsb2JhbABFhhKFX7R3gQiCIAEBAQMBEgEKBkgNBgsLGAkWCwICCQMCAQIBRQYBDAYCAQEXB4dcBpxWjSGTB4tYhV2BEgOVb45NgWuCcQ X-IronPort-AV: E=Sophos;i="4.80,613,1344211200"; d="scan'208,217";a="145535486" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 19 Oct 2012 16:11:23 +0000 Received: from dhcp-10-61-100-206.cisco.com (dhcp-10-61-100-206.cisco.com [10.61.100.206]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q9JGBMuj019618 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Oct 2012 16:11:22 GMT Message-ID: <50817BA9.6020503@cisco.com> Date: Fri, 19 Oct 2012 18:11:21 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Ted Lemon , DHCP discussion list References: <9D3C0AC1-D5B1-4C25-AC47-4D08E3252D54@nominum.com> <50800059.3030503@viagenie.ca> <4E18E4F4-7E60-41F7-8700-83EF2CF1D4A4@employees.org> <219448E3-6A90-411D-A430-EDE011E5E75E@nominum.com> <50F411F4-D3C5-4CED-B9BD-5E552C61C5EE@employees.org> <35B57831-F31C-40D9-A34A-9469261F3636@employees.org> <50814AB3.9070307@cisco.com> <2D7C2D36-D308-4480-8858-9F5EF23EDC06@nominum.com> In-Reply-To: <2D7C2D36-D308-4480-8858-9F5EF23EDC06@nominum.com> X-Enigmail-Version: 1.4.5 Content-Type: multipart/alternative; boundary="------------050309030502080409000901" Subject: Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-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, 19 Oct 2012 16:11:25 -0000 This is a multi-part message in MIME format. --------------050309030502080409000901 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Ted, Many points: On 10/19/12 4:38 PM, Ted Lemon wrote: > On Oct 19, 2012, at 8:42 AM, Eliot Lear wrote: >> The work is substantially complete in softwires, and while overlap in some cases happens, it should happen for good reason. Ole has explained that the case you are attempting to cover is already covered by the softwires draft, and I haven't yet heard any serious argument for development of an IPv4 option. If either WG later decides that an IPv4 option IS required it should be based on the existing softwires work. > It's not really within softwires' bailiwick to decide how the DHCP protocol will be extended. I want to answer your statement in three ways. First, in my reading of the draft, it makes no changes to classic DHCP behavior. Therefore, it seems to me that the protocol itself is not changed. Rather this Just Another Option (JAO). Where do you see differently? Given the authors of the draft are dhc regulars, I wouldn't really expect otherwise. Next, there's the bureaucratic way: This is what we have charters and ADs for. Did the softwire group exceed its charter? Let's go to the video tape: > Sep 2011 Submit DHCPv4 over tunnel document for Proposed Standard > I *think* this is what draft-ietf-softwire-map-dhcp-01 is meant to respond to. I will readily state that charters can often cause confusion. Area Directors are responsible for seeing that work occurs in the right place within the IETF. > Ordinarily we would expect any such work to be done in the DHC working group. My personal preference is to do DHCP options in the dhc working group simply because the experts are there, but as you well know, you can argue both sides of this issue if there is another competent working group. That is– if the underlying meaning of this option is within the expertise of softwire, then work done here might get overlooked by them. Fortunately, both you and the softwire WG chairs are experienced enough to recognize all of this. > And indeed quite some time ago people came from softwires to talk about whether to use DHCPv4 or DHCPv6 to solve this problem, and the working group decided to use DHCPv4 and not DHCPv6, for reasons I described in a separate message. So then I think you have a complaint against the existing softwire draft that is worthy of a last call comment, and others might as well. This is how we end up with one good standard and not two substandard standards, especially if it breaks DHCP. I'd suggest that at least one of the intarea directors knows something about DHCP, and would also take issue with something that breaks it ;-0 > > So it may be that softwires has continued on in a different direction since then, but the DHC working group has been working steadily on a solution involving DHCPv4, and it's a bit late to be telling us now that softwires has decided to go against the DHC consensus and break DHCPv6. I'm sorry, but I take issue with "late". We are at the point of adoption of a draft. This is PRECISELY the point when one must raise a concern. Eliot --------------050309030502080409000901 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Ted,

Many points:

On 10/19/12 4:38 PM, Ted Lemon wrote:
On Oct 19, 2012, at 8:42 AM, Eliot Lear <lear@cisco.com> wrote:

The work is substantially complete in softwires, and while overlap in some cases happens, it should happen for good reason.  Ole has explained that the case you are attempting to cover is already covered by the softwires draft, and I haven't yet heard any serious argument for development of an IPv4 option.  If either WG later decides that an IPv4 option IS required it should be based on the existing softwires work.

It's not really within softwires' bailiwick to decide how the DHCP protocol will be extended.

I want to answer your statement in three ways.  First, in my reading of the draft, it makes no changes to classic DHCP behavior.  Therefore, it seems to me that the protocol itself is not changed.  Rather this Just Another Option (JAO).  Where do you see differently?  Given the authors of the draft are dhc regulars, I wouldn't really expect otherwise.

Next, there's the bureaucratic way:

This is what we have charters and ADs for.  Did the softwire group exceed its charter?  Let's go to the video tape:

Sep 2011 Submit DHCPv4 over tunnel document for Proposed Standard
I *think* this is what draft-ietf-softwire-map-dhcp-01 is meant to respond to.  I will readily state that charters can often cause confusion.  Area Directors are responsible for seeing that work occurs in the right place within the IETF.  


   Ordinarily we would expect any such work to be done in the DHC working group.

My personal preference is to do DHCP options in the dhc working group simply because the experts are there, but as you well know, you can argue both sides of this issue if there is another competent working group.  That is– if the underlying meaning of this option is within the expertise of softwire, then work done here might get overlooked by them.  Fortunately, both you and the softwire WG chairs are experienced enough to recognize all of this.

And indeed quite some time ago people came from softwires to talk about whether to use DHCPv4 or DHCPv6 to solve this problem, and the working group decided to use DHCPv4 and not DHCPv6, for reasons I described in a separate message.

So then I think you have a complaint against the existing softwire draft that is worthy of a last call comment, and others might as well.  This is how we end up with one good standard and not two substandard standards, especially if it breaks DHCP.  I'd suggest that at least one of the intarea directors knows something about DHCP, and would also take issue with something that breaks it ;-0


So it may be that softwires has continued on in a different direction since then, but the DHC working group has been working steadily on a solution involving DHCPv4, and it's a bit late to be telling us now that softwires has decided to go against the DHC consensus and break DHCPv6.

I'm sorry, but I take issue with "late".  We are at the point of adoption of a draft.  This is PRECISELY the point when one must raise a concern.

Eliot
--------------050309030502080409000901-- From Ted.Lemon@nominum.com Fri Oct 19 09:30:57 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 024A321F8745 for ; Fri, 19 Oct 2012 09:30:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.495 X-Spam-Level: X-Spam-Status: No, score=-106.495 tagged_above=-999 required=5 tests=[AWL=0.104, 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 BwaClqiH0lnY for ; Fri, 19 Oct 2012 09:30:56 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id DB10421F85AE for ; Fri, 19 Oct 2012 09:30:55 -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 DSNKUIGAPyAzThU4K4hFPLUjdUj1Za1gxDJG@postini.com; Fri, 19 Oct 2012 09:30:55 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 1E2A31B8359 for ; Fri, 19 Oct 2012 09:30:55 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 1352019005C; Fri, 19 Oct 2012 09:30:55 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Fri, 19 Oct 2012 09:30:49 -0700 From: Ted Lemon To: Eliot Lear Thread-Topic: [dhcwg] Call for adoption: draft-sun-dhc-port-set-option Thread-Index: AQHNput68Hhly3n5akOtNZsf4t9jOpe/NbeAgABWX4CAAARBgIAAAb6AgAABPwCAAAUAAIAAARwAgAAMdICAAAMNAIABJiyAgAAWt4CAADARgIAAIF4AgAAaAICAAAVvAA== Date: Fri, 19 Oct 2012 16:30:48 +0000 Message-ID: <122FD73F-CC04-4AA3-9511-33FE6E734332@nominum.com> References: <9D3C0AC1-D5B1-4C25-AC47-4D08E3252D54@nominum.com> <50800059.3030503@viagenie.ca> <4E18E4F4-7E60-41F7-8700-83EF2CF1D4A4@employees.org> <219448E3-6A90-411D-A430-EDE011E5E75E@nominum.com> <50F411F4-D3C5-4CED-B9BD-5E552C61C5EE@employees.org> <35B57831-F31C-40D9-A34A-9469261F3636@employees.org> <50814AB3.9070307@cisco.com> <2D7C2D36-D308-4480-8858-9F5EF23EDC06@nominum.com> <50817BA9.6020503@cisco.com> In-Reply-To: <50817BA9.6020503@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: DHCP discussion list Subject: Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-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, 19 Oct 2012 16:30:57 -0000 On Oct 19, 2012, at 12:11 PM, Eliot Lear wrote: > I'm sorry, but I take issue with "late". We are at the point of adoption= of a draft. This is PRECISELY the point when one must raise a concern. No, we are not at the point of adoption of the relevant draft. We are at = the point of adoption of a follow-on draft. The decision as to what direc= tion to go in was taken over a year ago, and the work is essentially comple= te. It may be that the obvious problem with the solution proposed in softwires = isn't obvious to everyone, so let me explain in detail. Suppose for instance you have a port set allocation policy that gives 4096 = ports to each CPE device. In this situation, you have 12 bits of port and= 4 bits of address in the port range, and 32 bits of address in the IPv4 ad= dress range, for a total of 36 address bits. In order to allocate the port set, we need to know what IPv4 address the cl= ient has, since port sets are only unique to a specific IPv4 address. If = the DHCPv6 server allocates the port set, it must first learn somehow what = IPv4 address has been assigned to the CPE device. Furthermore, there will= be a time period between when the IPv4 address is first allocated and when= the port set is allocated when the device is unaware that it is sharing it= s IPv4 address, and may make connections using ports outside of the port se= t it will eventually be assigned. So it doesn't make sense to do the IPv4 address assignment in the DHCPv4 se= rver, and the port set assignment in the DHCPv6 server. Indeed, that simp= ly won't work, for most widely-accepted values of "work." The real problem that needs to be solved for port set allocation is how to = combine an IPv4 address and a port set. Effectively, the IPv4 address and= the port range add up to an address that is somewhere between 32 and 48 bi= ts wide, although numbers approaching 48 are obviously not very useful. I= t is easiest to treat this as a simple prefix assignment problem with a 48-= bit address, rather than as two separate problems: a port set assignment an= d an address assignment. Now, it's entirely possible to solve this problem in the DHCPv6 server. N= obody would dispute that. But what the softwires draft does is not that= =97it simply solves half the problem, and leaves the other half unaddressed= : it assigns a port set, but not an IPv4 address. As I say, to me this is painfully obvious, and so the implication is that s= ince softwires is attempting to advance a DHCPv6 option to solve the port s= et allocation problem, they have rejected the use of DHCPv4 to allocate IPv= 4 addresses in the port set allocation context. It may be that the author= s of the softwires draft had no such intention, but this is undeniably the = effect that their draft would have if it became the standard. From wdec.ietf@gmail.com Fri Oct 19 10:15:30 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D219C21F86B0 for ; Fri, 19 Oct 2012 10:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.072 X-Spam-Level: X-Spam-Status: No, score=-3.072 tagged_above=-999 required=5 tests=[AWL=0.526, 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 4lJPGTqV8DYY for ; Fri, 19 Oct 2012 10:15:29 -0700 (PDT) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id D6E3921F8827 for ; Fri, 19 Oct 2012 10:15:28 -0700 (PDT) Received: by mail-ea0-f172.google.com with SMTP id k13so269106eaa.31 for ; Fri, 19 Oct 2012 10:15:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AT/Gwd4zVzF6FP3Vl8dnTFUVmr4I2Iz7nkZs9rSZUL8=; b=bvxnx3LeICh3fyft46h4kRemejJ6dMNZK7AboJkRh38DWFSJFKxgM3EfvJ7Yf0SVN2 G0oT2hYqG9K3mNCN6FCHad/yzbdDejCfKa6v0eifArbJPTK4Ey6oOOFPWG6iLM0/QVTe hVEew51Wnnm0+0wP1YB7NZs/gbIpr41wUUdcLyzNklW2Ql8cbhEI5XTgT6RdfWr9C9CM g4eUCzURpAZ5gtJrxr0JO5ESI+0yaPm0ycjbC01OU2yBfEtiybDTVxVqhotiy2AFIgKc 6AXHCeyteQIVFRsUEtym4pYtebpGqXikv36euDoLyhk8U64J6I63yNOeomqMFi5kvH3B U41g== MIME-Version: 1.0 Received: by 10.14.193.136 with SMTP id k8mr2901453een.30.1350666927993; Fri, 19 Oct 2012 10:15:27 -0700 (PDT) Received: by 10.14.128.71 with HTTP; Fri, 19 Oct 2012 10:15:27 -0700 (PDT) In-Reply-To: <122FD73F-CC04-4AA3-9511-33FE6E734332@nominum.com> References: <9D3C0AC1-D5B1-4C25-AC47-4D08E3252D54@nominum.com> <50800059.3030503@viagenie.ca> <4E18E4F4-7E60-41F7-8700-83EF2CF1D4A4@employees.org> <219448E3-6A90-411D-A430-EDE011E5E75E@nominum.com> <50F411F4-D3C5-4CED-B9BD-5E552C61C5EE@employees.org> <35B57831-F31C-40D9-A34A-9469261F3636@employees.org> <50814AB3.9070307@cisco.com> <2D7C2D36-D308-4480-8858-9F5EF23EDC06@nominum.com> <50817BA9.6020503@cisco.com> <122FD73F-CC04-4AA3-9511-33FE6E734332@nominum.com> Date: Fri, 19 Oct 2012 19:15:27 +0200 Message-ID: From: Wojciech Dec To: Ted Lemon Content-Type: multipart/alternative; boundary=047d7b343e3673f30404cc6ca654 Cc: DHCP discussion list Subject: Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-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, 19 Oct 2012 17:15:30 -0000 --047d7b343e3673f30404cc6ca654 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Ted, As hopefully you'll concede, the sharing IPv4 addresses is a wider architecture/solution than just defining extensions in DHC. Following the charter the DHC should play an advisory role on the DHC part, rather than getting into the merits of port range discussions or not which this thread featured prominently - a tell tell sign of something really amiss in this work being in DHC. And it does not make things right by claiming that the discussion on that, or another aspect of the solution has been had in DHC for some time already= . Also, as asked previously, is there a case for for the DHCPv4 port extension, other than the softwire solutions? Thanks, Woj. On 19 October 2012 18:30, Ted Lemon wrote: > On Oct 19, 2012, at 12:11 PM, Eliot Lear wrote: > > I'm sorry, but I take issue with "late". We are at the point of > adoption of a draft. This is PRECISELY the point when one must raise a > concern. > > No, we are not at the point of adoption of the relevant draft. We are a= t > the point of adoption of a follow-on draft. The decision as to what > direction to go in was taken over a year ago, and the work is essentially > complete. > > It may be that the obvious problem with the solution proposed in softwire= s > isn't obvious to everyone, so let me explain in detail. > > Suppose for instance you have a port set allocation policy that gives 409= 6 > ports to each CPE device. In this situation, you have 12 bits of port a= nd > 4 bits of address in the port range, and 32 bits of address in the IPv4 > address range, for a total of 36 address bits. > > In order to allocate the port set, we need to know what IPv4 address the > client has, since port sets are only unique to a specific IPv4 address. > If the DHCPv6 server allocates the port set, it must first learn somehow > what IPv4 address has been assigned to the CPE device. Furthermore, the= re > will be a time period between when the IPv4 address is first allocated an= d > when the port set is allocated when the device is unaware that it is > sharing its IPv4 address, and may make connections using ports outside of > the port set it will eventually be assigned. > > So it doesn't make sense to do the IPv4 address assignment in the DHCPv4 > server, and the port set assignment in the DHCPv6 server. Indeed, that > simply won't work, for most widely-accepted values of "work." > > The real problem that needs to be solved for port set allocation is how t= o > combine an IPv4 address and a port set. Effectively, the IPv4 address a= nd > the port range add up to an address that is somewhere between 32 and 48 > bits wide, although numbers approaching 48 are obviously not very useful. > It is easiest to treat this as a simple prefix assignment problem with a > 48-bit address, rather than as two separate problems: a port set assignme= nt > and an address assignment. > > Now, it's entirely possible to solve this problem in the DHCPv6 server. > Nobody would dispute that. But what the softwires draft does is not > that=97it simply solves half the problem, and leaves the other half > unaddressed: it assigns a port set, but not an IPv4 address. > > As I say, to me this is painfully obvious, and so the implication is that > since softwires is attempting to advance a DHCPv6 option to solve the por= t > set allocation problem, they have rejected the use of DHCPv4 to allocate > IPv4 addresses in the port set allocation context. It may be that the > authors of the softwires draft had no such intention, but this is > undeniably the effect that their draft would have if it became the standa= rd. > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > --047d7b343e3673f30404cc6ca654 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Ted,

As hopefully you'll concede, the sharing IPv4 addresses is = a wider architecture/solution than just defining extensions in DHC. Followi= ng the charter the DHC should play an advisory role on the DHC part, rather= than getting into the merits of port range discussions or not which this t= hread featured prominently - a tell tell sign of something really amiss in = this work being in DHC.
And it does not make things right by claiming that the discussion on that, = or another aspect of the solution has been had in DHC for some time already= .
Also, as asked previously, is there a case for for the DHCPv4 port ext= ension, other than the softwire solutions?

Thanks,
Woj.

On 19 October 2012 18= :30, Ted Lemon <Ted.Lemon@nominum.com> wrote:
On Oct 19, 2012, at 12:11 PM, Eliot Lear <lear@cisco.com> wrote:
> I'm sorry, but I take issue with "late". =A0We are at th= e point of adoption of a draft. =A0This is PRECISELY the point when one mus= t raise a concern.

No, we are not at the point of adoption of the relevant draft. =A0 We= are at the point of adoption of a follow-on draft. =A0 The decision as to = what direction to go in was taken over a year ago, and the work is essentia= lly complete.

It may be that the obvious problem with the solution proposed in softwires = isn't obvious to everyone, so let me explain in detail.

Suppose for instance you have a port set allocation policy that gives 4096 = ports to each CPE device. =A0 In this situation, you have 12 bits of port a= nd 4 bits of address in the port range, and 32 bits of address in the IPv4 = address range, for a total of 36 address bits.

In order to allocate the port set, we need to know what IPv4 address the cl= ient has, since port sets are only unique to a specific IPv4 address. =A0 I= f the DHCPv6 server allocates the port set, it must first learn somehow wha= t IPv4 address has been assigned to the CPE device. =A0 Furthermore, there = will be a time period between when the IPv4 address is first allocated and = when the port set is allocated when the device is unaware that it is sharin= g its IPv4 address, and may make connections using ports outside of the por= t set it will eventually be assigned.

So it doesn't make sense to do the IPv4 address assignment in the DHCPv= 4 server, and the port set assignment in the DHCPv6 server. =A0 Indeed, tha= t simply won't work, for most widely-accepted values of "work.&quo= t;

The real problem that needs to be solved for port set allocation is how to = combine an IPv4 address and a port set. =A0 Effectively, the IPv4 address a= nd the port range add up to an address that is somewhere between 32 and 48 = bits wide, although numbers approaching 48 are obviously not very useful. = =A0 It is easiest to treat this as a simple prefix assignment problem with = a 48-bit address, rather than as two separate problems: a port set assignme= nt and an address assignment.

Now, it's entirely possible to solve this problem in the DHCPv6 server.= =A0 Nobody would dispute that. =A0 But what the softwires draft does is no= t that=97it simply solves half the problem, and leaves the other half unadd= ressed: it assigns a port set, but not an IPv4 address.

As I say, to me this is painfully obvious, and so the implication is that s= ince softwires is attempting to advance a DHCPv6 option to solve the port s= et allocation problem, they have rejected the use of DHCPv4 to allocate IPv= 4 addresses in the port set allocation context. =A0 It may be that the auth= ors of the softwires draft had no such intention, but this is undeniably th= e effect that their draft would have if it became the standard.

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

--047d7b343e3673f30404cc6ca654-- From Ted.Lemon@nominum.com Fri Oct 19 10:33:25 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F23B21F8864 for ; Fri, 19 Oct 2012 10:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.496 X-Spam-Level: X-Spam-Status: No, score=-106.496 tagged_above=-999 required=5 tests=[AWL=0.103, 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 X7K-2gEEftSL for ; Fri, 19 Oct 2012 10:33:25 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id AD17F21F87E1 for ; Fri, 19 Oct 2012 10:33:24 -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 DSNKUIGO5NE/tlLZ9yyXBn2ss1G50HbC3uhL@postini.com; Fri, 19 Oct 2012 10:33: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 DD46D1B8358 for ; Fri, 19 Oct 2012 10:33:23 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id D214619005C; Fri, 19 Oct 2012 10:33:23 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Fri, 19 Oct 2012 10:33:23 -0700 From: Ted Lemon To: Wojciech Dec Thread-Topic: [dhcwg] Call for adoption: draft-sun-dhc-port-set-option Thread-Index: AQHNput68Hhly3n5akOtNZsf4t9jOpe/NbeAgABWX4CAAARBgIAAAb6AgAABPwCAAAUAAIAAARwAgAAMdICAAAMNAIABJiyAgAAWt4CAADARgIAAIF4AgAAaAICAAAVvAIAADHqAgAAFAoA= Date: Fri, 19 Oct 2012 17:33:23 +0000 Message-ID: <3680FD68-458F-4918-9FA1-83EF34B38063@nominum.com> References: <9D3C0AC1-D5B1-4C25-AC47-4D08E3252D54@nominum.com> <50800059.3030503@viagenie.ca> <4E18E4F4-7E60-41F7-8700-83EF2CF1D4A4@employees.org> <219448E3-6A90-411D-A430-EDE011E5E75E@nominum.com> <50F411F4-D3C5-4CED-B9BD-5E552C61C5EE@employees.org> <35B57831-F31C-40D9-A34A-9469261F3636@employees.org> <50814AB3.9070307@cisco.com> <2D7C2D36-D308-4480-8858-9F5EF23EDC06@nominum.com> <50817BA9.6020503@cisco.com> <122FD73F-CC04-4AA3-9511-33FE6E734332@nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <24704D8492C22D4980E33D456DB669D9@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: DHCP discussion list Subject: Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-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, 19 Oct 2012 17:33:25 -0000 On Oct 19, 2012, at 1:15 PM, Wojciech Dec wrote: > As hopefully you'll concede, the sharing IPv4 addresses is a wider archit= ecture/solution than just defining extensions in DHC. Following the charter= the DHC should play an advisory role on the DHC part, rather than getting = into the merits of port range discussions or not which this thread featured= prominently - a tell tell sign of something really amiss in this work bein= g in DHC. > And it does not make things right by claiming that the discussion on that= , or another aspect of the solution has been had in DHC for some time alrea= dy. > Also, as asked previously, is there a case for for the DHCPv4 port extens= ion, other than the softwire solutions?=20 Do you have anything substantive to say? It's really a lot of work to wri= te out a document explaining the problem on a technical level. It's dishe= artening to read a response that completely ignores the explanation and jus= t talks about politics. From wdec.ietf@gmail.com Fri Oct 19 10:47:14 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2FD821F85ED for ; Fri, 19 Oct 2012 10:47:14 -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 KfGN6lwKRyZM for ; Fri, 19 Oct 2012 10:47:14 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id BA99A21F8794 for ; Fri, 19 Oct 2012 10:47:13 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id d4so367566eek.31 for ; Fri, 19 Oct 2012 10:47:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PABQ410KGU++0DpJ2YU+V4BZSuKiQ7znMexN01a8X0U=; b=xRoPMFGF5nSoQEgvXpx5vQICht2EZI6ybjLh3cad/kLO/qZ2Dh/zkqOW0WovDYt6Ls Nfp7xnbwHk3KVw/VJZW74hK9DT0UOiKA2NL/URPZIaHEZsriS1YrLazEl3hl/TDuwIRQ NAS5rhKNDSXSxMHt665Qiq2W5wMv8pZr286iwwFBPDOvA1FcINaxSrF/KKghFrHAlT2O A6JvDfViUSmmQqDRyyyKE2oWTkgT88SbiRvRhd05WcjUNMFibHCWX4oVOYhYdpv4F5Aj FcNjbiUaaklo1zPPKurriI4NGi1diDI84mChio+jPVOAUkTNwE48stBft10Cccz6W0VT Ks4w== MIME-Version: 1.0 Received: by 10.14.193.136 with SMTP id k8mr3007230een.30.1350668832919; Fri, 19 Oct 2012 10:47:12 -0700 (PDT) Received: by 10.14.128.71 with HTTP; Fri, 19 Oct 2012 10:47:12 -0700 (PDT) In-Reply-To: <3680FD68-458F-4918-9FA1-83EF34B38063@nominum.com> References: <9D3C0AC1-D5B1-4C25-AC47-4D08E3252D54@nominum.com> <50800059.3030503@viagenie.ca> <4E18E4F4-7E60-41F7-8700-83EF2CF1D4A4@employees.org> <219448E3-6A90-411D-A430-EDE011E5E75E@nominum.com> <50F411F4-D3C5-4CED-B9BD-5E552C61C5EE@employees.org> <35B57831-F31C-40D9-A34A-9469261F3636@employees.org> <50814AB3.9070307@cisco.com> <2D7C2D36-D308-4480-8858-9F5EF23EDC06@nominum.com> <50817BA9.6020503@cisco.com> <122FD73F-CC04-4AA3-9511-33FE6E734332@nominum.com> <3680FD68-458F-4918-9FA1-83EF34B38063@nominum.com> Date: Fri, 19 Oct 2012 19:47:12 +0200 Message-ID: From: Wojciech Dec To: Ted Lemon Content-Type: multipart/alternative; boundary=047d7b343e36fecf7c04cc6d17ec Cc: DHCP discussion list Subject: Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-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, 19 Oct 2012 17:47:15 -0000 --047d7b343e36fecf7c04cc6d17ec Content-Type: text/plain; charset=ISO-8859-1 On 19 October 2012 19:33, Ted Lemon wrote: > On Oct 19, 2012, at 1:15 PM, Wojciech Dec > wrote: > > As hopefully you'll concede, the sharing IPv4 addresses is a wider > architecture/solution than just defining extensions in DHC. Following the > charter the DHC should play an advisory role on the DHC part, rather than > getting into the merits of port range discussions or not which this thread > featured prominently - a tell tell sign of something really amiss in this > work being in DHC. > > And it does not make things right by claiming that the discussion on > that, or another aspect of the solution has been had in DHC for some time > already. > > Also, as asked previously, is there a case for for the DHCPv4 port > extension, other than the softwire solutions? > > Do you have anything substantive to say? It's really a lot of work to > write out a document explaining the problem on a technical level. It's > disheartening to read a response that completely ignores the explanation > and just talks about politics. > > Perhaps it may be worthwhile for you to consider writing that document then and share it with the rest of us who apparently are not as well informed. It's also disheartening to see the DHC chair get ruffled by a debate on port range formats, which have next to nothing to do with the DHCP protocol, and ignore basic questions about the scope of the work. -Woj. --047d7b343e36fecf7c04cc6d17ec Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 19 October 2012 19:33, Ted Lemon <Ted.Lemon@nominum.com> wrote:
On Oct 19, 2012, at 1:15 PM, Wojciech Dec <wdec.ietf@gmail.com>
=A0wrote:
> As hopefully you'll concede, the sharing IPv4 addresses is a wider= architecture/solution than just defining extensions in DHC. Following the = charter the DHC should play an advisory role on the DHC part, rather than g= etting into the merits of port range discussions or not which this thread f= eatured prominently - a tell tell sign of something really amiss in this wo= rk being in DHC.
> And it does not make things right by claiming that the discussion on t= hat, or another aspect of the solution has been had in DHC for some time al= ready.
> Also, as asked previously, is there a case for for the DHCPv4 port ext= ension, other than the softwire solutions?

Do you have anything substantive to say? =A0 It's really a lot of= work to write out a document explaining the problem on a technical level. = =A0 It's disheartening to read a response that completely ignores the e= xplanation and just talks about politics.

Perhaps it may be worthwhile for you to consider writing= that document then and share it with the rest of us who apparently are not= as well informed.
It's also disheartening to see the DHC chair get = ruffled by a debate on port range formats, which have next to nothing to do= with the DHCP protocol, and ignore basic questions about the scope of the = work.

-Woj.


--047d7b343e36fecf7c04cc6d17ec-- From wdec.ietf@gmail.com Fri Oct 19 10:53:31 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 503EC21F8645 for ; Fri, 19 Oct 2012 10:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.138 X-Spam-Level: X-Spam-Status: No, score=-3.138 tagged_above=-999 required=5 tests=[AWL=0.460, 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 mrgEywQn+rpc for ; Fri, 19 Oct 2012 10:53:29 -0700 (PDT) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 56FFA21F85B0 for ; Fri, 19 Oct 2012 10:53:29 -0700 (PDT) Received: by mail-ea0-f172.google.com with SMTP id k13so281234eaa.31 for ; Fri, 19 Oct 2012 10:53:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0hUX2Vz3/d+fkpzxP0bifdzMiSJHjIJNcXe/8Xy5DnA=; b=EaZb/GzOea66uPFD4hgFUc/dDmJvOc7ERnEdyzhsMaPDXQIwz5jYLRIIiaMh/ORgfC XgN2m051hViY4h6I4TS29v4QnjfQqmjK69a8dozRTd2KibbwoccaOOaeMyaXasrl58o7 J1qyWS4DHejm1xbg9xhc1tBT0Xyf+xQodpLReggoGn0f9LmekUB4hItxn+IxquHezX4J 1MF5Qu/uaZtGM8MC3H3l9Bh3++RKCUpPQ847UN1gScle5QmxNoOaQQ3LyeDKV5Be6TOv cul2tPeHdidyzsZ5gdAqGv3QAqz+I0X+jv3Tb8VdjiyfELiEWQ82zWXtwE4ezrtUB3T4 wDbA== MIME-Version: 1.0 Received: by 10.14.193.136 with SMTP id k8mr3028439een.30.1350669208479; Fri, 19 Oct 2012 10:53:28 -0700 (PDT) Received: by 10.14.128.71 with HTTP; Fri, 19 Oct 2012 10:53:28 -0700 (PDT) In-Reply-To: References: <9D3C0AC1-D5B1-4C25-AC47-4D08E3252D54@nominum.com> <50800059.3030503@viagenie.ca> <4E18E4F4-7E60-41F7-8700-83EF2CF1D4A4@employees.org> <219448E3-6A90-411D-A430-EDE011E5E75E@nominum.com> <50F411F4-D3C5-4CED-B9BD-5E552C61C5EE@employees.org> <35B57831-F31C-40D9-A34A-9469261F3636@employees.org> <50814AB3.9070307@cisco.com> <2D7C2D36-D308-4480-8858-9F5EF23EDC06@nominum.com> <50817BA9.6020503@cisco.com> <122FD73F-CC04-4AA3-9511-33FE6E734332@nominum.com> <3680FD68-458F-4918-9FA1-83EF34B38063@nominum.com> Date: Fri, 19 Oct 2012 19:53:28 +0200 Message-ID: From: Wojciech Dec To: Ted Lemon Content-Type: multipart/alternative; boundary=047d7b343e3661674004cc6d2e01 Cc: DHCP discussion list Subject: Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-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, 19 Oct 2012 17:53:31 -0000 --047d7b343e3661674004cc6d2e01 Content-Type: text/plain; charset=ISO-8859-1 On 19 October 2012 19:47, Wojciech Dec wrote: > > > On 19 October 2012 19:33, Ted Lemon wrote: > >> On Oct 19, 2012, at 1:15 PM, Wojciech Dec >> wrote: >> > As hopefully you'll concede, the sharing IPv4 addresses is a wider >> architecture/solution than just defining extensions in DHC. Following the >> charter the DHC should play an advisory role on the DHC part, rather than >> getting into the merits of port range discussions or not which this thread >> featured prominently - a tell tell sign of something really amiss in this >> work being in DHC. >> > And it does not make things right by claiming that the discussion on >> that, or another aspect of the solution has been had in DHC for some time >> already. >> > Also, as asked previously, is there a case for for the DHCPv4 port >> extension, other than the softwire solutions? >> >> Do you have anything substantive to say? It's really a lot of work to >> write out a document explaining the problem on a technical level. It's >> disheartening to read a response that completely ignores the explanation >> and just talks about politics. >> >> Perhaps it may be worthwhile for you to consider writing that document > then and share it with the rest of us who apparently are not as well > informed. > It's also disheartening to see the DHC chair get ruffled by a debate on > port range formats, which have next to nothing to do with the DHCP > protocol, and ignore basic questions about the scope of the work. > Forgot to add : Your analysis appears to have overlooked a characteristic of MAP; the IPv4 address can be derived from a combination of IPv4 and IPv6 info. More stuff in http://tools.ietf.org/agenda/84/slides/slides-84-softwire-13.pdf (which was discussed in softwires) > -Woj. > > > --047d7b343e3661674004cc6d2e01 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 19 October 2012 19:47, Wojciech Dec <= span dir=3D"ltr"><wdec.ietf@gmail.com> wrote:


= On 19 October 2012 19:33, Ted Lemon <Ted.Lemon@nominum.com> wrote:
On Oct 19, 2012, at 1:15 PM, Wojciech Dec <wdec.ietf@gmail.com>
=A0wrote:
> As hopefully you'll concede, the sharing IPv4 addresses is a wider= architecture/solution than just defining extensions in DHC. Following the = charter the DHC should play an advisory role on the DHC part, rather than g= etting into the merits of port range discussions or not which this thread f= eatured prominently - a tell tell sign of something really amiss in this wo= rk being in DHC.
> And it does not make things right by claiming that the discussion on t= hat, or another aspect of the solution has been had in DHC for some time al= ready.
> Also, as asked previously, is there a case for for the DHCPv4 port ext= ension, other than the softwire solutions?

Do you have anything substantive to say? =A0 It's really a lot of= work to write out a document explaining the problem on a technical level. = =A0 It's disheartening to read a response that completely ignores the e= xplanation and just talks about politics.

Perhaps it may be worthwhile for you to cons= ider writing that document then and share it with the rest of us who appare= ntly are not as well informed.
It's also disheartening to see the DH= C chair get ruffled by a debate on port range formats, which have next to n= othing to do with the DHCP protocol, and ignore basic questions about the s= cope of the work.

Forgot to add : Your analysis appears to have overloo= ked a characteristic of MAP; the IPv4 address can be derived from a combina= tion of IPv4 and IPv6 info.
More stuff in http://tools.ietf.org/agenda= /84/slides/slides-84-softwire-13.pdf (which was discussed in softwires)=



-Woj.



--047d7b343e3661674004cc6d2e01-- From Ted.Lemon@nominum.com Fri Oct 19 10:57:19 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0820A21F8438 for ; Fri, 19 Oct 2012 10:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.497 X-Spam-Level: X-Spam-Status: No, score=-106.497 tagged_above=-999 required=5 tests=[AWL=0.102, 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 qhNIFbuPQxoy for ; Fri, 19 Oct 2012 10:57:18 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id 4F19121F8428 for ; Fri, 19 Oct 2012 10:57:18 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKUIGUfTtalhbWM197+pWEuRh1idOkX57k@postini.com; Fri, 19 Oct 2012 10:57:18 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 3EE901B8359 for ; Fri, 19 Oct 2012 10:57:15 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 367A919005C; Fri, 19 Oct 2012 10:57:15 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Fri, 19 Oct 2012 10:57:08 -0700 From: Ted Lemon To: Wojciech Dec Thread-Topic: [dhcwg] Call for adoption: draft-sun-dhc-port-set-option Thread-Index: AQHNput68Hhly3n5akOtNZsf4t9jOpe/NbeAgABWX4CAAARBgIAAAb6AgAABPwCAAAUAAIAAARwAgAAMdICAAAMNAIABJiyAgAAWt4CAADARgIAAIF4AgAAaAICAAAVvAIAADHqAgAAFAoCAAAPdAIAAAsWA Date: Fri, 19 Oct 2012 17:57:08 +0000 Message-ID: References: <9D3C0AC1-D5B1-4C25-AC47-4D08E3252D54@nominum.com> <50800059.3030503@viagenie.ca> <4E18E4F4-7E60-41F7-8700-83EF2CF1D4A4@employees.org> <219448E3-6A90-411D-A430-EDE011E5E75E@nominum.com> <50F411F4-D3C5-4CED-B9BD-5E552C61C5EE@employees.org> <35B57831-F31C-40D9-A34A-9469261F3636@employees.org> <50814AB3.9070307@cisco.com> <2D7C2D36-D308-4480-8858-9F5EF23EDC06@nominum.com> <50817BA9.6020503@cisco.com> <122FD73F-CC04-4AA3-9511-33FE6E734332@nominum.com> <3680FD68-458F-4918-9FA1-83EF34B38063@nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: DHCP discussion list Subject: Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-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, 19 Oct 2012 17:57:19 -0000 On Oct 19, 2012, at 1:47 PM, Wojciech Dec wrote: > Perhaps it may be worthwhile for you to consider writing that document th= en and share it with the rest of us who apparently are not as well informed= . I just did. The rest of your response tells me that you didn't read it. = Could you please go back and read it? This is not a debate about port ra= nge formats. From wdec.ietf@gmail.com Fri Oct 19 11:24:59 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3A7521F85AE for ; Fri, 19 Oct 2012 11:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.319 X-Spam-Level: X-Spam-Status: No, score=-3.319 tagged_above=-999 required=5 tests=[AWL=0.279, 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 vQ1bR3xNDnbY for ; Fri, 19 Oct 2012 11:24:59 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA5A21F859E for ; Fri, 19 Oct 2012 11:24:58 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id d4so382168eek.31 for ; Fri, 19 Oct 2012 11:24:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3cqWMvpnrOeT74NALDXl/OFSns+lROk7qo7GRhH6Qcw=; b=j9cCY+veFCspPFshDwqtLRC5qRztnmUbc6pjvlO5sHNGcYJB2X4cq4L2fKUBlEVnzq h0y13gSSZlQD7Rw4goFkWHYjEqkn7AcZvkx55aII8NXLXglV5SWQ9deGuwUfPKXYnkgD t+TDmZ7A2KN6nS8ilkrDjo/EfaSueJf04JhSDUqHDekD5w6XZzgA0QsByhxNn2T518Ay hdsEW1xQzm/aMbMy6ji7aghBzvOeQHSGKaRBao+h4heqK2k4ndIyzt/QweHn8KV35n1/ dTr+qxLT/FIBYpFLQoH5hocGpHiJb/TtA492LRAM5QDO1RtUf2/mjpo/rwtsNJwkB6JT YYOw== MIME-Version: 1.0 Received: by 10.14.0.198 with SMTP id 46mr3183860eeb.21.1350671098083; Fri, 19 Oct 2012 11:24:58 -0700 (PDT) Received: by 10.14.128.71 with HTTP; Fri, 19 Oct 2012 11:24:57 -0700 (PDT) In-Reply-To: References: <9D3C0AC1-D5B1-4C25-AC47-4D08E3252D54@nominum.com> <50800059.3030503@viagenie.ca> <4E18E4F4-7E60-41F7-8700-83EF2CF1D4A4@employees.org> <219448E3-6A90-411D-A430-EDE011E5E75E@nominum.com> <50F411F4-D3C5-4CED-B9BD-5E552C61C5EE@employees.org> <35B57831-F31C-40D9-A34A-9469261F3636@employees.org> <50814AB3.9070307@cisco.com> <2D7C2D36-D308-4480-8858-9F5EF23EDC06@nominum.com> <50817BA9.6020503@cisco.com> <122FD73F-CC04-4AA3-9511-33FE6E734332@nominum.com> <3680FD68-458F-4918-9FA1-83EF34B38063@nominum.com> Date: Fri, 19 Oct 2012 20:24:57 +0200 Message-ID: From: Wojciech Dec To: Ted Lemon Content-Type: multipart/alternative; boundary=047d7b62275e0279e204cc6d9f63 Cc: DHCP discussion list Subject: Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-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, 19 Oct 2012 18:24:59 -0000 --047d7b62275e0279e204cc6d9f63 Content-Type: text/plain; charset=ISO-8859-1 On 19 October 2012 19:57, Ted Lemon wrote: > On Oct 19, 2012, at 1:47 PM, Wojciech Dec > wrote: > > Perhaps it may be worthwhile for you to consider writing that document > then and share it with the rest of us who apparently are not as well > informed. > > I just did. The rest of your response tells me that you didn't read it. > Could you please go back and read it? This is not a debate about port > range formats. > > If that is the extent of it, then your analysis appears to have overlooked a characteristic of MAP; the IPv4 address can be derived from a combination of IPv4 and IPv6 info. More stuff in http://tools.ietf.org/agenda/84/slides/slides-84-softwire-13.pdf (which was discussed in softwires) that indicates plenty of overlap between the solutions. As others have said, picking and defining an option in DHC without consideration of the overall work appears short sighted. Dismissing the charter aspect also - unless your assertion is that charters don't matter. --047d7b62275e0279e204cc6d9f63 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 19 October 2012 19:57, Ted Lemon <Ted.Lemon@nominum.com> wrote:
On Oct 19, 2012, at 1:47 PM, Wojciech Dec <wdec.ietf@gmail.com>
=A0wrote:
> Perhaps it may be worthwhile for you to consider writing that document= then and share it with the rest of us who apparently are not as well infor= med.

I just did. =A0 The rest of your response tells me that you didn'= t read it. =A0 Could you please go back and read it? =A0 This is not a deba= te about port range formats.

If that is the extent of it, then your analysis appears = to have overlooked a characteristic of MAP; the=20 IPv4 address can be derived from a combination of IPv4 and IPv6 info.
Mo= re stuff in http://tools.ietf.org/agenda/84/slides/slid= es-84-softwire-13.pdf (which was discussed in softwires) that indicates= plenty of overlap between the solutions.

As others have said, picking and defining an option in DHC without cons= ideration of the overall work appears short sighted. Dismissing the charter= aspect also - unless your assertion is that charters don't matter.
--047d7b62275e0279e204cc6d9f63-- From lear@cisco.com Fri Oct 19 11:26:29 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B310521F87D8 for ; Fri, 19 Oct 2012 11:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.424 X-Spam-Level: X-Spam-Status: No, score=-110.424 tagged_above=-999 required=5 tests=[AWL=0.175, 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 InCkJzae9gm7 for ; Fri, 19 Oct 2012 11:26:28 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id EDCA221F8567 for ; Fri, 19 Oct 2012 11:26:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=593; q=dns/txt; s=iport; t=1350671188; x=1351880788; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=TqmIHSG8o4h0cg6iQQb10bX2Og/Sa90AEoIFOtTCwU8=; b=CoOqoO7PbA1m3E8zxivB9Dv3GCHFfV1J7p+N0t+WbPZEKKuCHjQg7tlV GJYHCIdxZREWPXQgTEgBrt+OOenld76cqONW28EOwMzvvqVSYQc0IbOlg cbD4Nf8Z4qVrmLuwVd28orwqyiy8fNKU7KT9bsxyRNKsp/nfosyifSNlb Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoEJAMSZgVCQ/khL/2dsb2JhbABFhU1HuUkEBIEHgQiCIAEBAQQSAQoGVQEQCxgCAgUWCwICCQMCAQIBDzYGDQEFAgEBHodQAw+cFY0hiSMNiVSBIIlSaIVdgRIDlBmBVosogyWBa4Jx X-IronPort-AV: E=Sophos;i="4.80,613,1344211200"; d="scan'208";a="77605462" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 19 Oct 2012 18:26:26 +0000 Received: from dhcp-10-61-100-206.cisco.com (dhcp-10-61-100-206.cisco.com [10.61.100.206]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9JIQP4w013536 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Oct 2012 18:26:25 GMT Message-ID: <50819B50.1000308@cisco.com> Date: Fri, 19 Oct 2012 20:26:24 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Ted Lemon References: <9D3C0AC1-D5B1-4C25-AC47-4D08E3252D54@nominum.com> <4E18E4F4-7E60-41F7-8700-83EF2CF1D4A4@employees.org> <219448E3-6A90-411D-A430-EDE011E5E75E@nominum.com> <50F411F4-D3C5-4CED-B9BD-5E552C61C5EE@employees.org> <35B57831-F31C-40D9-A34A-9469261F3636@employees.org> <50814AB3.9070307@cisco.com> <2D7C2D36-D308-4480-8858-9F5EF23EDC06@nominum.com> <50817BA9.6020503@cisco.com> <122FD73F-CC04-4AA3-9511-33FE6E734332@nominum.com> <3680FD68-458F-4918-9FA1-83EF34B38063@nominum.com> In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: DHCP discussion list Subject: Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-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, 19 Oct 2012 18:26:29 -0000 I think we've crossed the threshold where perhaps this is a good topic for the ADs, chairs, and perhaps some high bandwidth time in Atlanta? On 10/19/12 7:57 PM, Ted Lemon wrote: > On Oct 19, 2012, at 1:47 PM, Wojciech Dec > wrote: >> Perhaps it may be worthwhile for you to consider writing that document then and share it with the rest of us who apparently are not as well informed. > I just did. The rest of your response tells me that you didn't read it. Could you please go back and read it? This is not a debate about port range formats. > > > From Ted.Lemon@nominum.com Fri Oct 19 14:57:36 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1954E21F850B for ; Fri, 19 Oct 2012 14:57:36 -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 VD-PossI8-Jk for ; Fri, 19 Oct 2012 14:57:35 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id 6B08E21F8562 for ; Fri, 19 Oct 2012 14:57:34 -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 DSNKUIHMzcjggmTCJh6zUNHKsU2NBR9NKXlQ@postini.com; Fri, 19 Oct 2012 14:57:34 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 7605C1B8237 for ; Fri, 19 Oct 2012 14:57:33 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 6982C19005C; Fri, 19 Oct 2012 14:57:33 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Fri, 19 Oct 2012 14:57:33 -0700 From: Ted Lemon To: Wojciech Dec Thread-Topic: [dhcwg] Call for adoption: draft-sun-dhc-port-set-option Thread-Index: AQHNput68Hhly3n5akOtNZsf4t9jOpe/NbeAgABWX4CAAARBgIAAAb6AgAABPwCAAAUAAIAAARwAgAAMdICAAAMNAIABJiyAgAAWt4CAADARgIAAIF4AgAAaAICAAAVvAIAADHqAgAAFAoCAAAPdAIAAAsWAgAAHx4CAADsgAA== Date: Fri, 19 Oct 2012 21:57:32 +0000 Message-ID: <593BA8E0-0564-48C2-AE99-F7E05F53EF74@nominum.com> References: <9D3C0AC1-D5B1-4C25-AC47-4D08E3252D54@nominum.com> <50800059.3030503@viagenie.ca> <4E18E4F4-7E60-41F7-8700-83EF2CF1D4A4@employees.org> <219448E3-6A90-411D-A430-EDE011E5E75E@nominum.com> <50F411F4-D3C5-4CED-B9BD-5E552C61C5EE@employees.org> <35B57831-F31C-40D9-A34A-9469261F3636@employees.org> <50814AB3.9070307@cisco.com> <2D7C2D36-D308-4480-8858-9F5EF23EDC06@nominum.com> <50817BA9.6020503@cisco.com> <122FD73F-CC04-4AA3-9511-33FE6E734332@nominum.com> <3680FD68-458F-4918-9FA1-83EF34B38063@nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <1603D2D2C1A42943BC4E24ADB1406ACD@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: DHCP discussion list Subject: Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-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, 19 Oct 2012 21:57:36 -0000 On Oct 19, 2012, at 2:24 PM, Wojciech Dec wrote: > If that is the extent of it, then your analysis appears to have overlooke= d a characteristic of MAP; the IPv4 address can be derived from a combinati= on of IPv4 and IPv6 info. > More stuff in http://tools.ietf.org/agenda/84/slides/slides-84-softwire-1= 3.pdf (which was discussed in softwires) that indicates plenty of overlap b= etween the solutions. The slides don't actually describe how that's done. > As others have said, picking and defining an option in DHC without consid= eration of the overall work appears short sighted. Dismissing the charter a= spect also - unless your assertion is that charters don't matter. The DHC working group is chartered with doing DHCP extensions. It's true that if you have a static mapping between IPv4 and IPv6 address, = you don't need DHCPv4. However, it's not clear to me that this is univers= ally desired. From otroan@employees.org Fri Oct 19 18:51:48 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13F1B21F8645 for ; Fri, 19 Oct 2012 18:51:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AdMPiOCnMd91 for ; Fri, 19 Oct 2012 18:51:47 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 47EAE21F85FE for ; Fri, 19 Oct 2012 18:51:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,618,1344211200"; d="scan'208";a="59238267" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 20 Oct 2012 01:51:47 +0000 Received: from [10.61.100.251] (dhcp-10-61-100-251.cisco.com [10.61.100.251]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9K1phdC003702 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 20 Oct 2012 01:51:46 GMT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: =?windows-1252?Q?Ole_Tr=F8an?= In-Reply-To: <122FD73F-CC04-4AA3-9511-33FE6E734332@nominum.com> Date: Sat, 20 Oct 2012 03:51:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4E480F55-103E-434D-8170-21FD476430CC@employees.org> References: <9D3C0AC1-D5B1-4C25-AC47-4D08E3252D54@nominum.com> <50800059.3030503@viagenie.ca> <4E18E4F4-7E60-41F7-8700-83EF2CF1D4A4@employees.org> <219448E3-6A90-411D-A430-EDE011E5E75E@nominum.com> <50F411F4-D3C5-4CED-B9BD-5E552C61C5EE@employees.org> <35B57831-F31C-40D9-A34A-9469261F3636@employees.org> <50814AB3.9070307@cisco.com> <2D7C2D36-D308-4480-8858-9F5EF23EDC06@nominum.com> <50817BA9.6020503@cisco.com> <122FD73F-CC04-4AA3-9511-33FE6E734332@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1498) Cc: DHCP discussion list Subject: Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-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, 20 Oct 2012 01:51:48 -0000 Ted, > The real problem that needs to be solved for port set allocation is = how to combine an IPv4 address and a port set. Effectively, the IPv4 = address and the port range add up to an address that is somewhere = between 32 and 48 bits wide, although numbers approaching 48 are = obviously not very useful. It is easiest to treat this as a simple = prefix assignment problem with a 48-bit address, rather than as two = separate problems: a port set assignment and an address assignment. >=20 > Now, it's entirely possible to solve this problem in the DHCPv6 = server. Nobody would dispute that. But what the softwires draft does = is not that=97it simply solves half the problem, and leaves the other = half unaddressed: it assigns a port set, but not an IPv4 address. >=20 > As I say, to me this is painfully obvious, and so the implication is = that since softwires is attempting to advance a DHCPv6 option to solve = the port set allocation problem, they have rejected the use of DHCPv4 to = allocate IPv4 addresses in the port set allocation context. It may be = that the authors of the softwires draft had no such intention, but this = is undeniably the effect that their draft would have if it became the = standard. the above is plain wrong. draft-ietf-softwire-map + draft-ietf-softwire-map-dhcp does let you = allocate an IPv4 address, or an IPv4 prefix (does IPv4 prefix = delegation), or allocate an shared IPv4 address (A+P). all this is done = with a DHCPv6 option. with or without embedded address bits. just like DHCPv4 option 212 is used to allocate an IPv6 prefix, the MAP = DHCPv6 option is used to allocate IPv4 parameters. cheers, Ole= From Ted.Lemon@nominum.com Fri Oct 19 21:10:05 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8CB821F882E for ; Fri, 19 Oct 2012 21:10:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.35 X-Spam-Level: X-Spam-Status: No, score=-106.35 tagged_above=-999 required=5 tests=[AWL=-0.051, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 w+5+uksR9574 for ; Fri, 19 Oct 2012 21:10:05 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 09B4021F889B for ; Fri, 19 Oct 2012 21:10:05 -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 DSNKUIIkHM2tuUyxNJ3YqHGaS0roZ1n9OS3/@postini.com; Fri, 19 Oct 2012 21:10: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 0009D1B8264 for ; Fri, 19 Oct 2012 21:10:03 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id E5D0319005C; Fri, 19 Oct 2012 21:10:03 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Fri, 19 Oct 2012 21:09:57 -0700 From: Ted Lemon To: =?Windows-1252?Q?Ole_Tr=F8an?= Thread-Topic: [dhcwg] Call for adoption: draft-sun-dhc-port-set-option Thread-Index: AQHNput68Hhly3n5akOtNZsf4t9jOpe/NbeAgABWX4CAAARBgIAAAb6AgAABPwCAAAUAAIAAARwAgAAMdICAAAMNAIABJiyAgAAWt4CAADARgIAAIF4AgAAaAICAAAVvAIAAnLcAgAAmnwA= Date: Sat, 20 Oct 2012 04:09:56 +0000 Message-ID: <52B0D3A8-CB35-42AB-9A21-0FE83BFA59B7@nominum.com> References: <9D3C0AC1-D5B1-4C25-AC47-4D08E3252D54@nominum.com> <50800059.3030503@viagenie.ca> <4E18E4F4-7E60-41F7-8700-83EF2CF1D4A4@employees.org> <219448E3-6A90-411D-A430-EDE011E5E75E@nominum.com> <50F411F4-D3C5-4CED-B9BD-5E552C61C5EE@employees.org> <35B57831-F31C-40D9-A34A-9469261F3636@employees.org> <50814AB3.9070307@cisco.com> <2D7C2D36-D308-4480-8858-9F5EF23EDC06@nominum.com> <50817BA9.6020503@cisco.com> <122FD73F-CC04-4AA3-9511-33FE6E734332@nominum.com> <4E480F55-103E-434D-8170-21FD476430CC@employees.org> In-Reply-To: <4E480F55-103E-434D-8170-21FD476430CC@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: DHCP discussion list Subject: Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-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, 20 Oct 2012 04:10:05 -0000 On Oct 19, 2012, at 9:51 PM, Ole Tr=F8an wrote: > draft-ietf-softwire-map + draft-ietf-softwire-map-dhcp does let you alloc= ate an IPv4 address, or an IPv4 prefix (does IPv4 prefix delegation), or al= locate an shared IPv4 address (A+P). all this is done with a DHCPv6 option.= with or without embedded address bits. You are confusing representation with mechanism. What is the mechanism wh= ereby this address is allocated? From pengwu.thu@gmail.com Fri Oct 19 23:29:24 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2826021F85B3 for ; Fri, 19 Oct 2012 23:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.367 X-Spam-Level: X-Spam-Status: No, score=-3.367 tagged_above=-999 required=5 tests=[AWL=-0.068, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 cNcUkG1NeEvd for ; Fri, 19 Oct 2012 23:29:23 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1921021F8585 for ; Fri, 19 Oct 2012 23:29:22 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so1421200vcb.31 for ; Fri, 19 Oct 2012 23:29:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=I1droQsKbbYWRLE+euKRp+SOE+4U7Q/YEa/3IhQY90s=; b=NI14kRJcrO3/55Z40uqu7XjHb3uHrtuEwR96il/rH2mmY0TasdxahjKiSqIAY0ELSS mde5DooND3P5UjJlXAwhI709jzQz0I5RunEvxAoqfacmQzJnhtCc/Co0N8LEFkFN2Y3E Qsc+r2GVHdjv6sHpQRvqNgy2uaoY/os7N755h2LjfiWGGV0PlenEC6tcw+8m2wtuJBxC alhX5+U7eOJZQ6HbWSEEK1tmP2dNXdW+VhwXsGjcbip8v7s/16EW5LvlY9lqzuSgTgot QoeDYy7dLRN/VfpNreBTNo600oXolMCtR80QM1qGLZ1mXidC4GaorN5EyeN4D+4bwFLN F/Gg== MIME-Version: 1.0 Received: by 10.52.180.131 with SMTP id do3mr3500378vdc.112.1350714562515; Fri, 19 Oct 2012 23:29:22 -0700 (PDT) Received: by 10.58.163.102 with HTTP; Fri, 19 Oct 2012 23:29:22 -0700 (PDT) In-Reply-To: References: <9D3C0AC1-D5B1-4C25-AC47-4D08E3252D54@nominum.com> <50800059.3030503@viagenie.ca> <4E18E4F4-7E60-41F7-8700-83EF2CF1D4A4@employees.org> <219448E3-6A90-411D-A430-EDE011E5E75E@nominum.com> <50F411F4-D3C5-4CED-B9BD-5E552C61C5EE@employees.org> <6ED6C0E5-48E1-4E10-A190-40998201D449@gmail.com> Date: Sat, 20 Oct 2012 14:29:22 +0800 Message-ID: From: Peng Wu To: =?ISO-8859-1?Q?Ole_Tr=F8an?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "" , Ted Lemon Subject: Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-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, 20 Oct 2012 06:29:24 -0000 On Thu, Oct 18, 2012 at 10:53 PM, Ole Tr=F8an wrote: >>> if this proposal is also advocating a contiguous mask, then I don't und= erstand why you cannot use the proposal in draft-ietf-softwire-map? >> >> The proposal in draft-ietf-softwire-map includes case of allocating non= -contiguous port-sets to a CE. Non-contiguous port-set can't make it harder= to guess the port, with extra effort for implementation. A contiguous por= t-set is enough and can be achieved easily. > > MAP isn't encoded the way it is to make it hard to guess, it is to avoid = the well known ports, without reserving a particular "port set id" as you c= all it. > > with an offset =3D 0, you get your scheme with MAP. This doesn't seem convincing to me. You have to reserve something to avoid well-known ports. Now instead of reserving one port-set id for an entire address, MAP requires that the left a bits (A (j)) cannot be zero, i.e., reserve a PORT RANGE in EACH PORT SET. So I don't think this is the reason to have MAP to support non-contiguous port set... From pengwu.thu@gmail.com Fri Oct 19 23:37:33 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2DC821F8585 for ; Fri, 19 Oct 2012 23:37:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.511 X-Spam-Level: X-Spam-Status: No, score=-3.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 7Hnp6eiKWtEV for ; Fri, 19 Oct 2012 23:37:33 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1792121F8584 for ; Fri, 19 Oct 2012 23:37:32 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so1424957vcb.31 for ; Fri, 19 Oct 2012 23:37:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=kTzeMw/7cjSQ/hktUzxwVin7X8GFmTx1gnBJF/J/G9w=; b=jsGIZOMbSy4+I0zQcxFFYqlQcqi3Nhk8/ZKyAD9t4J6+2NiQWXGZA8pGmVlcEjGLw3 p2tqoaVJ8WkJWxh/lJeeq+669xr+Ss6bnQzwFrwLXwuQTq+hUTCaGEOWzNmaAPsykHXb H5jon9EjRRNfm2D8qcPCzXnDY0y0MNUAWGKxDVHNC8vCkfMjlJuhr9aUDHv5sfI+OMtg 13BVb5eiVrCw6iOEa0PxMnrvdOGazf8mU4IcDifD+Qk4gaR5UUnkDO7DRuxQaaH/kyG9 Wy6/+IFfFWx1xjR3h5W9eqOioNdx3WsvF0krQlKfHrwe0aqle+e4bWHU5DcfDKIApkcQ gjOQ== MIME-Version: 1.0 Received: by 10.58.162.130 with SMTP id ya2mr4764062veb.2.1350715052548; Fri, 19 Oct 2012 23:37:32 -0700 (PDT) Received: by 10.58.163.102 with HTTP; Fri, 19 Oct 2012 23:37:32 -0700 (PDT) In-Reply-To: References: <9D3C0AC1-D5B1-4C25-AC47-4D08E3252D54@nominum.com> <50800059.3030503@viagenie.ca> <4E18E4F4-7E60-41F7-8700-83EF2CF1D4A4@employees.org> <219448E3-6A90-411D-A430-EDE011E5E75E@nominum.com> Date: Sat, 20 Oct 2012 14:37:32 +0800 Message-ID: From: Peng Wu To: Wojciech Dec Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "" , Ted Lemon Subject: Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-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, 20 Oct 2012 06:37:33 -0000 Sorry Woj, but please don't mislead the discussion here. Softwire approves the separate existance of per-flow stateful solution, per-subscriber stateful solution and stateless solutions for IPv4-over-IPv6, at least that's one of the outcomes of the Vancouver Softwire meeting I participated in. If you do per-subscriber stateful solution, you provision IPv4 address and port range explicitly. it's kind of straightforward, right? On Thu, Oct 18, 2012 at 11:05 PM, Wojciech Dec wrote: > > > On 18 October 2012 15:34, Ted Lemon wrote: >> >> On Oct 18, 2012, at 9:28 AM, Ole Tr=F8an >> wrote: >> > without a "larger context" (i.e. some sort of encapsulation, how is th= at >> > supposed to work? think ARP. >> >> Just to be clear here, the DHC working group is not proposing to work on >> defining a way to share IP addresses. The DHC working group is proposi= ng >> to work on a way to convey a port range to a device which shares IP >> addresses, using DHCP. Anything more than that would definitely be out= of >> scope for DHC. > > > It may be worthwhile to ask "why" then are these ranges needed, if not fo= r > the specific solutions in softwires? > The sharing of IP addresses on a "regular v4" network has been documente= d > as "bad", > http://tools.ietf.org/html/draft-thaler-port-restricted-ip-issues-00 > > Now, given that there are several nuances of the solutions for "v4 networ= ks > over v6", with address sharing, it stands to reason that the solution gro= up > defining these should also define the option and consult DHC accordingly, > rather than the other way round. > > Regards, > Woj. >> >> >> BTW, we discussed using port ranges versus using masks; the reason for >> using masks is that it's easier to do on the fast path than ranges. >> >> _______________________________________________ >> 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 pengwu.thu@gmail.com Sat Oct 20 00:00:28 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F68E21F88F7 for ; Sat, 20 Oct 2012 00:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.518 X-Spam-Level: X-Spam-Status: No, score=-3.518 tagged_above=-999 required=5 tests=[AWL=0.080, 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 8+OX7NepJ1oD for ; Sat, 20 Oct 2012 00:00:27 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id B0E1F21F873A for ; Sat, 20 Oct 2012 00:00:19 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so1465108vbb.31 for ; Sat, 20 Oct 2012 00:00:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5X5/YtmK5ZvaMwaK/Z8IZNEB+xa4k9pdKQ07Iwl8Peg=; b=FfUqITMkAl+CFdQ6mYlUhDg8b1bSWKFtMoN/pInggpXBMwhppVA7kZG9RX6Rffb5uT epcbb6H9Z0fw41TSeSKgtK6dm4BH+CfV3dtWGBOD7oOTVV2uIGFmdULH6bqWZ1MGKCXs 1CeIm70fhgg7sO40xsKzQSlqdMOuNcom9cYU8pfvwOS+IE26rwC+eRSZMBgZ78tiS4e6 9MWgLbF1DfWMgY2dL87I769UJ4nnYHOwQX22JRn6hpW5pXxG9yxGwi4Sk7yCl/kQHaBP ndp1zgftOVJIQ8HkZXzAnTb6HP6vojpm8275tAEtPLvDZcN/eK5s7pU0/eH+wQGRiUTl vK3Q== MIME-Version: 1.0 Received: by 10.220.150.145 with SMTP id y17mr4517575vcv.11.1350716418640; Sat, 20 Oct 2012 00:00:18 -0700 (PDT) Received: by 10.58.163.102 with HTTP; Sat, 20 Oct 2012 00:00:18 -0700 (PDT) In-Reply-To: <50817BA9.6020503@cisco.com> References: <9D3C0AC1-D5B1-4C25-AC47-4D08E3252D54@nominum.com> <50800059.3030503@viagenie.ca> <4E18E4F4-7E60-41F7-8700-83EF2CF1D4A4@employees.org> <219448E3-6A90-411D-A430-EDE011E5E75E@nominum.com> <50F411F4-D3C5-4CED-B9BD-5E552C61C5EE@employees.org> <35B57831-F31C-40D9-A34A-9469261F3636@employees.org> <50814AB3.9070307@cisco.com> <2D7C2D36-D308-4480-8858-9F5EF23EDC06@nominum.com> <50817BA9.6020503@cisco.com> Date: Sat, 20 Oct 2012 15:00:18 +0800 Message-ID: From: Peng Wu To: Eliot Lear Content-Type: multipart/alternative; boundary=f46d043d67e9534ce404cc782c3f Cc: DHCP discussion list , Ted Lemon Subject: Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-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, 20 Oct 2012 07:00:28 -0000 --f46d043d67e9534ce404cc782c3f Content-Type: text/plain; charset=ISO-8859-1 Eliot, On Sat, Oct 20, 2012 at 12:11 AM, Eliot Lear wrote: > > Next, there's the bureaucratic way: > > This is what we have charters and ADs for. Did the softwire group exceed > its charter? Let's go to the video tape: > > Sep 2011 Submit DHCPv4 over tunnel document for Proposed Standard > > I *think* this is what draft-ietf-softwire-map-dhcp-01 is meant to respond > to. I will readily state that charters can often cause confusion. Area > Directors are responsible for seeing that work occurs in the right place > within the IETF. > For the record, this refers to the DHCPv4-over-IPv6 draft indeed. The draft was originally submitted to Softwire http://tools.ietf.org/html/draft-cui-softwire-dhcp-over-tunnel-01 Then during the Quebec meeting last year, the softwire chairs and our AD who is responsible for both softwire and DHC decided to MOVE this effort TO DHC because it was decoupled from the softwire solutions and essentially became a DHC problem. Therefore we resubmit this document to DHC http://tools.ietf.org/id/draft-cui-dhc-dhcpv4-over-ipv6-00.txt And later it was adopted as http://tools.ietf.org/id/draft-ietf-dhc-dhcpv4-over-ipv6-00.txt So if we are talking about this, please at least respect the history. --f46d043d67e9534ce404cc782c3f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Eliot,

On Sat, Oct 20, 2012 at 12:11 AM, = Eliot Lear <lear@cisco.com> wrote:
=20 =20 =20
=A0=A0=A0
Next, there's the bureaucratic way:

This is what we have charters and ADs for.=A0 Did the softwire group exceed its charter?=A0 Let's go to the video tape:

=20
Sep 2011 Submit DHCPv4 over tunnel document for Proposed Standard
I *think* this is what draft-ietf-softwire-map-dhcp-01 is meant to respond to.=A0 I will readily state that charters can often cause confusion.=A0 Area Directors are responsible for seeing that work occurs in the right place within the IETF.=A0
For the record, this refers to the DHCPv4-over-IPv6 draft indeed.
<= div>The draft was originally submitted to Softwire http://tools.ietf.org= /html/draft-cui-softwire-dhcp-over-tunnel-01
Then during the Quebec meeting last year, the softwire chairs and=A0ou= r AD who is responsible for both softwire and DHC decided to MOVE this effo= rt=A0TO DHC because it was=A0decoupled from=A0the softwire solutions and es= sentially became a DHC problem.=A0
Therefore we resubmit this document to DHC http://tools.ietf.org/id/dr= aft-cui-dhc-dhcpv4-over-ipv6-00.txt
And later it was adopted = as=A0 http://tools.ietf.org/id/draft-ietf-dhc-dhcpv4-over-ipv6-00.txt<= /div>
=A0
So if we are talking about this, please at least respect= the history.
--f46d043d67e9534ce404cc782c3f-- From lear@cisco.com Sat Oct 20 00:13:58 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25EC621F84C0 for ; Sat, 20 Oct 2012 00:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.427 X-Spam-Level: X-Spam-Status: No, score=-110.427 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 YdJa7Q+h6H2s for ; Sat, 20 Oct 2012 00:13:57 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 937CD21F84BC for ; Sat, 20 Oct 2012 00:13:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6277; q=dns/txt; s=iport; t=1350717236; x=1351926836; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=2gzGnec0x0Ydd6y8quCVa4Owhumt1D0ZrpqizcIEs2g=; b=MYrf2So8aMpCW84GAXU/nLVh/NpTHNxPWababtWWRsu/FMLg5vK6vsFl Jsj448XNMrvaPOqgU3cNz2Q+BrHcRcMg4a4X3P9mWEAQ759oH3zUf0Y64 Jb4LmfbN6SN+1m4fd05dUyA7lqzuNK+txX6XgI0Ak0ytg6RGsziYheInw 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqcFAPNNglCQ/khR/2dsb2JhbABFhhSFX7UagQiCIAEBAQMBEgEKBlUBBQsLGAkWCAMCAgkDAgECATQRBg0BBQIBARcHh1wGC5t9jSGSSotahV2BEgOVboEXjTaBa4Jx X-IronPort-AV: E=Sophos;i="4.80,619,1344211200"; d="scan'208,217";a="8963014" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-4.cisco.com with ESMTP; 20 Oct 2012 07:13:55 +0000 Received: from dhcp-10-61-101-133.cisco.com (dhcp-10-61-101-133.cisco.com [10.61.101.133]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9K7Ds6q028799 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 20 Oct 2012 07:13:55 GMT Message-ID: <50824F32.1090602@cisco.com> Date: Sat, 20 Oct 2012 09:13:54 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Peng Wu References: <9D3C0AC1-D5B1-4C25-AC47-4D08E3252D54@nominum.com> <50800059.3030503@viagenie.ca> <4E18E4F4-7E60-41F7-8700-83EF2CF1D4A4@employees.org> <219448E3-6A90-411D-A430-EDE011E5E75E@nominum.com> <50F411F4-D3C5-4CED-B9BD-5E552C61C5EE@employees.org> <35B57831-F31C-40D9-A34A-9469261F3636@employees.org> <50814AB3.9070307@cisco.com> <2D7C2D36-D308-4480-8858-9F5EF23EDC06@nominum.com> <50817BA9.6020503@cisco.com> In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: multipart/alternative; boundary="------------030208090806080505020504" Cc: DHCP discussion list , Ted Lemon Subject: Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-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, 20 Oct 2012 07:13:58 -0000 This is a multi-part message in MIME format. --------------030208090806080505020504 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Peng, Thanks for the clarification. Sometimes reading tea leaves is easier than reading charters and their intents. Again, however, two ways to do what is substantially similar in function and identically similar in purpose should be avoided. I appreciate Ted's recounting of his concerns. And I think he deserves a fair answer to the following question, which so far as I can tell is really what the argument is over: > You are confusing representation with mechanism. What is the mechanism whereby this address is allocated? Eliot On 10/20/12 9:00 AM, Peng Wu wrote: > Eliot, > > On Sat, Oct 20, 2012 at 12:11 AM, Eliot Lear > wrote: > > > Next, there's the bureaucratic way: > > This is what we have charters and ADs for. Did the softwire group > exceed its charter? Let's go to the video tape: > >> Sep 2011 Submit DHCPv4 over tunnel document for Proposed Standard >> > I *think* this is what draft-ietf-softwire-map-dhcp-01 is meant to > respond to. I will readily state that charters can often cause > confusion. Area Directors are responsible for seeing that work > occurs in the right place within the IETF. > > For the record, this refers to the DHCPv4-over-IPv6 draft indeed. > The draft was originally submitted to Softwire > http://tools.ietf.org/html/draft-cui-softwire-dhcp-over-tunnel-01 > Then during the Quebec meeting last year, the softwire chairs and our > AD who is responsible for both softwire and DHC decided to MOVE this > effort TO DHC because it was decoupled from the softwire solutions and > essentially became a DHC problem. > Therefore we resubmit this document to DHC > http://tools.ietf.org/id/draft-cui-dhc-dhcpv4-over-ipv6-00.txt > And later it was adopted as > http://tools.ietf.org/id/draft-ietf-dhc-dhcpv4-over-ipv6-00.txt > > So if we are talking about this, please at least respect the history. --------------030208090806080505020504 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Peng,

Thanks for the clarification.  Sometimes reading tea leaves is easier than reading charters and their intents.  Again, however, two ways to do what is substantially similar in function and identically similar in purpose should be avoided.  I appreciate Ted's recounting of his concerns.  And I think he deserves a fair answer to the following question, which so far as I can tell is really what the argument is over:

You are confusing representation with mechanism.   What is the mechanism whereby this address is allocated?

Eliot

On 10/20/12 9:00 AM, Peng Wu wrote:
Eliot,

On Sat, Oct 20, 2012 at 12:11 AM, Eliot Lear <lear@cisco.com> wrote:
   
Next, there's the bureaucratic way:

This is what we have charters and ADs for.  Did the softwire group exceed its charter?  Let's go to the video tape:

Sep 2011 Submit DHCPv4 over tunnel document for Proposed Standard
I *think* this is what draft-ietf-softwire-map-dhcp-01 is meant to respond to.  I will readily state that charters can often cause confusion.  Area Directors are responsible for seeing that work occurs in the right place within the IETF. 
For the record, this refers to the DHCPv4-over-IPv6 draft indeed.
The draft was originally submitted to Softwire http://tools.ietf.org/html/draft-cui-softwire-dhcp-over-tunnel-01
Then during the Quebec meeting last year, the softwire chairs and our AD who is responsible for both softwire and DHC decided to MOVE this effort TO DHC because it was decoupled from the softwire solutions and essentially became a DHC problem. 
Therefore we resubmit this document to DHC http://tools.ietf.org/id/draft-cui-dhc-dhcpv4-over-ipv6-00.txt
 
So if we are talking about this, please at least respect the history.

--------------030208090806080505020504-- From pengwu.thu@gmail.com Sat Oct 20 00:40:09 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2F8C21F85FE for ; Sat, 20 Oct 2012 00:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.523 X-Spam-Level: X-Spam-Status: No, score=-3.523 tagged_above=-999 required=5 tests=[AWL=0.075, 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 d8TFrlWNcII3 for ; Sat, 20 Oct 2012 00:40:08 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id A0F8321F85F5 for ; Sat, 20 Oct 2012 00:40:08 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so1484977vbb.31 for ; Sat, 20 Oct 2012 00:40:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hwcb4PkWKv1twxe1Y1trKhohqZoAPOYlSQCmFvx9zQE=; b=BULgTiq8sCYVGTqSVOl1au5ebQF0z7GLOR/TO0HAja4YKx8/15rK5zwyMiaArw7yfH 6o5Sz5RXd5QWztJo2IpIQtamYklgqFrARysXvR7H487AIpBR3/39wkoLeV4QVN/W0O5z CK786fje5LwYMxIWemxN1YsUM9nk+6Wd72twNfF4DQPRdaiiGvBhj/6cvLuiPRp++3qN sWmimdJNNzKOM1JmECFOFk53BHWachefOLT7aEz3m7bEev5mhGa6FzLLupB630XQeYn0 OfsGSl1vEtQBlW6aAZMAivCzxOO12XQTHsQF98zKIFOJZ+2LYCKZp5C4J6GJIO+T+tGT qETg== MIME-Version: 1.0 Received: by 10.52.89.172 with SMTP id bp12mr3694422vdb.19.1350718807881; Sat, 20 Oct 2012 00:40:07 -0700 (PDT) Received: by 10.58.163.102 with HTTP; Sat, 20 Oct 2012 00:40:07 -0700 (PDT) In-Reply-To: <50824F32.1090602@cisco.com> References: <9D3C0AC1-D5B1-4C25-AC47-4D08E3252D54@nominum.com> <50800059.3030503@viagenie.ca> <4E18E4F4-7E60-41F7-8700-83EF2CF1D4A4@employees.org> <219448E3-6A90-411D-A430-EDE011E5E75E@nominum.com> <50F411F4-D3C5-4CED-B9BD-5E552C61C5EE@employees.org> <35B57831-F31C-40D9-A34A-9469261F3636@employees.org> <50814AB3.9070307@cisco.com> <2D7C2D36-D308-4480-8858-9F5EF23EDC06@nominum.com> <50817BA9.6020503@cisco.com> <50824F32.1090602@cisco.com> Date: Sat, 20 Oct 2012 15:40:07 +0800 Message-ID: From: Peng Wu To: Eliot Lear Content-Type: multipart/alternative; boundary=bcaec5015f39bc385f04cc78baa6 Cc: DHCP discussion list , Ted Lemon Subject: Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-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, 20 Oct 2012 07:40:09 -0000 --bcaec5015f39bc385f04cc78baa6 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Oct 20, 2012 at 3:13 PM, Eliot Lear wrote: > Peng, > > Thanks for the clarification. Sometimes reading tea leaves is easier than > reading charters and their intents. Again, however, two ways to do what is > substantially similar in function and identically similar in purpose should > be avoided. I appreciate Ted's recounting of his > Ironically, no. With the map dhcpv6 option or map , it take the precondition of embedding ipv4 address and port into ipv6 (in most cases, which Ole claiming has the ability to assign address, prefix and shared address). By embedding ipv4 into ipv6, it could appear from the surface that we are allocating "ipv6" address, so dhcpv6 may fit in from this view. But Ted has the bigger point that we don't add v4 feature to v6 protocols which would be useless once v4 disappear. Then it include a total different case saying that, it could happen when there is no address embedding, then most of the former stuff doesn't fit. In this case, we are literrally allocating an ipv4 address, so even it's over ipv6 network layer, we absolutely need dhcpv4 protocol. An interesting fact is that with dhcpv4-over-ipv6,theoretically we can do both... > concerns. And I think he deserves a fair answer to the following > question, which so far as I can tell is really what the argument is over: > > > You are confusing representation with mechanism. What is the mechanism whereby this address is allocated? > > > Eliot > > > On 10/20/12 9:00 AM, Peng Wu wrote: > > Eliot, > > On Sat, Oct 20, 2012 at 12:11 AM, Eliot Lear wrote: > >> >> Next, there's the bureaucratic way: >> >> This is what we have charters and ADs for. Did the softwire group exceed >> its charter? Let's go to the video tape: >> >> Sep 2011 Submit DHCPv4 over tunnel document for Proposed Standard >> >> I *think* this is what draft-ietf-softwire-map-dhcp-01 is meant to >> respond to. I will readily state that charters can often cause confusion. >> Area Directors are responsible for seeing that work occurs in the right >> place within the IETF. >> > For the record, this refers to the DHCPv4-over-IPv6 draft indeed. > The draft was originally submitted to Softwire > http://tools.ietf.org/html/draft-cui-softwire-dhcp-over-tunnel-01 > Then during the Quebec meeting last year, the softwire chairs and our AD > who is responsible for both softwire and DHC decided to MOVE this effort TO > DHC because it was decoupled from the softwire solutions and essentially > became a DHC problem. > Therefore we resubmit this document to DHC > http://tools.ietf.org/id/draft-cui-dhc-dhcpv4-over-ipv6-00.txt > And later it was adopted as > http://tools.ietf.org/id/draft-ietf-dhc-dhcpv4-over-ipv6-00.txt > > So if we are talking about this, please at least respect the history. > > > --bcaec5015f39bc385f04cc78baa6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sat, Oct 20, 2012 at 3:13 PM, Eliot L= ear <lear@cisco.com> wrote:
=20 =20 =20
Peng,

Thanks for the clarification.=A0 Sometimes reading tea leaves is easier than reading charters and their intents.=A0 Again, however, two ways to do what is substantially similar in function and identically similar in purpose should be avoided.=A0 I appreciate Ted's recount= ing of his
Ironically, no. With the map dhcpv6 optio= n or map=A0,=A0it take the precondition of embedding ipv4 address and port = into ipv6 (in most cases, which Ole claiming has the ability to assign addr= ess, prefix and shared address). By embedding ipv4 into ipv6, it could appe= ar from the surface that we are allocating "ipv6" address, so dhc= pv6 may fit in from this view. But Ted has the bigger point that we don'= ;t add v4 feature to v6 protocols which would be useless once v4 disappear.=
Then it include a total different case saying that, it could happen wh= en there is no address embedding, then most of the former stuff doesn't= fit. In this case, we are literrally allocating an ipv4 address, so even i= t's over ipv6 network layer, we absolutely need dhcpv4 protocol.
=A0
An interesting fact is that=A0with dhcpv4-over-ipv6,theo= retically we can do both...
=A0
concerns.=A0 And I think he dese= rves a fair answer to the following question, which so far as I can tell is really what the argument is over:


You are confusing representation with mechanism.   What is the m=
echanism whereby this address is allocated?

Eliot


On 10/20/12 9:00 AM, Peng Wu wrote:
=20 Eliot,

On Sat, Oct 20, 2012 at 12:11 AM, Eliot Lear <lear@cisco.com> wrote:
=A0=A0=A0
Next, there's the bureaucratic way:

This is what we have charters and ADs for.=A0 Did the softwire group exceed its charter?=A0 Let's go to the video tape:
Sep 2011 Submit DHCPv4 over tunnel document for Proposed Standard
I *think* this is what draft-ietf-softwire-map-dhcp-01 is meant to respond to.=A0 I will readily state that charters can often cause confusion.=A0 Area Directors are responsible for seeing that work occurs in the right place within the IETF.=A0
For the record, this refers to the DHCPv4-over-IPv6 draft indeed.
The draft was originally submitted to Softwire http://tools.ietf.org/html/draft-cui-softwire-dhcp-over-tunnel-01=
Then during the Quebec meeting last year, the softwire chairs and=A0our AD who is responsible for both softwire and DHC decided to MOVE this effort=A0TO DHC because it was=A0decoupled from=A0the softwire solutions and essentially became a DHC problem.=A0
Therefore we resubmit this document to DHC h= ttp://tools.ietf.org/id/draft-cui-dhc-dhcpv4-over-ipv6-00.txt
=A0
So if we are talking about this, please at least respect the history.


--bcaec5015f39bc385f04cc78baa6-- From otroan@employees.org Sat Oct 20 01:50:54 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3943D21F85ED for ; Sat, 20 Oct 2012 01:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5VQuCuAxa7Xr for ; Sat, 20 Oct 2012 01:50:53 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 3761721F8640 for ; Sat, 20 Oct 2012 01:50:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,621,1344211200"; d="scan'208";a="58736362" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 20 Oct 2012 08:50:44 +0000 Received: from [10.61.100.251] (dhcp-10-61-100-251.cisco.com [10.61.100.251]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9K8oe90009393 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 20 Oct 2012 08:50:42 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Sat, 20 Oct 2012 10:50:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4DDC6ED5-C2FC-43A8-93D0-E06751D67FB9@employees.org> References: <9D3C0AC1-D5B1-4C25-AC47-4D08E3252D54@nominum.com> <50800059.3030503@viagenie.ca> <4E18E4F4-7E60-41F7-8700-83EF2CF1D4A4@employees.org> <219448E3-6A90-411D-A430-EDE011E5E75E@nominum.com> <50F411F4-D3C5-4CED-B9BD-5E552C61C5EE@employees.org> <35B57831-F31C-40D9-A34A-9469261F3636@employees.org> <50814AB3.9070307@cisco.com> <2D7C2D36-D308-4480-8858-9F5EF23EDC06@nominum.com> <50817BA9.6020503@cisco.com> <50824F32.1090602@cisco.com> To: Peng Wu X-Mailer: Apple Mail (2.1498) Cc: DHCP discussion list , Ted Lemon Subject: Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-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, 20 Oct 2012 08:50:54 -0000 Peng, Ted, > Thanks for the clarification. Sometimes reading tea leaves is easier = than reading charters and their intents. Again, however, two ways to do = what is substantially similar in function and identically similar in = purpose should be avoided. I appreciate Ted's recounting of his > Ironically, no. With the map dhcpv6 option or map , it take the = precondition of embedding ipv4 address and port into ipv6 (in most = cases, which Ole claiming has the ability to assign address, prefix and = shared address). By embedding ipv4 into ipv6, it could appear from the = surface that we are allocating "ipv6" address, so dhcpv6 may fit in from = this view. But Ted has the bigger point that we don't add v4 feature to = v6 protocols which would be useless once v4 disappear. > Then it include a total different case saying that, it could happen = when there is no address embedding, then most of the former stuff = doesn't fit. In this case, we are literrally allocating an ipv4 address, = so even it's over ipv6 network layer, we absolutely need dhcpv4 = protocol. this is just a corner case of the same mechanism. when no address bits = are embedded in IPv6 address, all of the IPv4 address bits and port = range bits are in the DHCPv6 option. and what you get is a "configured" = point to point IPv4 over IPv6 tunnel with no dependence between the = address families. > An interesting fact is that with dhcpv4-over-ipv6,theoretically we can = do both... by creating an application specific tunnel of IPv4 over IPv6. is _that_ = what we want to do? > concerns. And I think he deserves a fair answer to the following = question, which so far as I can tell is really what the argument is = over: >=20 >=20 >> You are confusing representation with mechanism. What is the = mechanism whereby this address is allocated? [answering Ted's question here as well] not sure I grok this question. the mechanism is that a MAP capable CPE = includes the MAP option in an ORO option. the DHCPv6 reply contains e.g. = the IPv4 address and port range and that IPv4 address and port range is = "assigned" to the outside of the NAT44 function. note, that it is not = and MUST NOT be assigned to an interface. so the normal IPv4 allocation = mechanism cannot be used. if this was based on the existing DHCPv4 address option, how would a = client know that the above restriction applies? cheers, Ole= From Ted.Lemon@nominum.com Sat Oct 20 08:06:17 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 530AE21F84DF for ; Sat, 20 Oct 2012 08:06:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.35 X-Spam-Level: X-Spam-Status: No, score=-106.35 tagged_above=-999 required=5 tests=[AWL=-0.051, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 EBUNqet+nWlM for ; Sat, 20 Oct 2012 08:06:16 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id 540FF21F84E9 for ; Sat, 20 Oct 2012 08:06:14 -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 DSNKUIK93jdsHSCjqpdnr8F+foDTqFnbX1de@postini.com; Sat, 20 Oct 2012 08:06:14 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 60C931B829B for ; Sat, 20 Oct 2012 08:06:06 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 5024B19005C; Sat, 20 Oct 2012 08:06:06 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Sat, 20 Oct 2012 08:06:06 -0700 From: Ted Lemon To: =?iso-8859-1?Q?Ole_Tr=F8an?= Thread-Topic: [dhcwg] Call for adoption: draft-sun-dhc-port-set-option Thread-Index: AQHNput68Hhly3n5akOtNZsf4t9jOpe/NbeAgABWX4CAAARBgIAAAb6AgAABPwCAAAUAAIAAARwAgAAMdICAAAMNAIABJiyAgAAWt4CAADARgIAAIF4AgAAaAICAAPhfAIAAA8wAgAAHU4CAABO1gIAAaOWA Date: Sat, 20 Oct 2012 15:06:05 +0000 Message-ID: <1EAF4610-FCE9-4DC0-B932-8DA1A3B34325@nominum.com> References: <9D3C0AC1-D5B1-4C25-AC47-4D08E3252D54@nominum.com> <50800059.3030503@viagenie.ca> <4E18E4F4-7E60-41F7-8700-83EF2CF1D4A4@employees.org> <219448E3-6A90-411D-A430-EDE011E5E75E@nominum.com> <50F411F4-D3C5-4CED-B9BD-5E552C61C5EE@employees.org> <35B57831-F31C-40D9-A34A-9469261F3636@employees.org> <50814AB3.9070307@cisco.com> <2D7C2D36-D308-4480-8858-9F5EF23EDC06@nominum.com> <50817BA9.6020503@cisco.com> <50824F32.1090602@cisco.com> <4DDC6ED5-C2FC-43A8-93D0-E06751D67FB9@employees.org> In-Reply-To: <4DDC6ED5-C2FC-43A8-93D0-E06751D67FB9@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <5ADA50D60ACA2744B63C3AF03E81FD01@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: DHCP discussion list Subject: Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-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, 20 Oct 2012 15:06:17 -0000 On Oct 20, 2012, at 4:50 AM, Ole Tr=F8an wrote: > by creating an application specific tunnel of IPv4 over IPv6. is _that_ w= hat we want to do? Where is this tunnel of which you speak? > not sure I grok this question. the mechanism is that a MAP capable CPE in= cludes the MAP option in an ORO option. the DHCPv6 reply contains e.g. the = IPv4 address and port range and that IPv4 address and port range is "assign= ed" to the outside of the NAT44 function. note, that it is not and MUST NO= T be assigned to an interface. so the normal IPv4 allocation mechanism cann= ot be used. > if this was based on the existing DHCPv4 address option, how would a clie= nt know that the above restriction applies? What allocation mechanism _is_ used? From otroan@employees.org Sat Oct 20 09:47:06 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B351821F8724 for ; Sat, 20 Oct 2012 09:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.266 X-Spam-Level: X-Spam-Status: No, score=-10.266 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 sw2fVNNyN5QJ for ; Sat, 20 Oct 2012 09:47:04 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 8B85021F8630 for ; Sat, 20 Oct 2012 09:47:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,622,1344211200"; d="scan'208";a="8960052" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-3.cisco.com with ESMTP; 20 Oct 2012 16:47:03 +0000 Received: from [10.61.100.248] (dhcp-10-61-100-248.cisco.com [10.61.100.248]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q9KGl38G001454 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 20 Oct 2012 16:47:03 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <1EAF4610-FCE9-4DC0-B932-8DA1A3B34325@nominum.com> Date: Sat, 20 Oct 2012 18:47:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9D3C0AC1-D5B1-4C25-AC47-4D08E3252D54@nominum.com> <50800059.3030503@viagenie.ca> <4E18E4F4-7E60-41F7-8700-83EF2CF1D4A4@employees.org> <219448E3-6A90-411D-A430-EDE011E5E75E@nominum.com> <50F411F4-D3C5-4CED-B9BD-5E552C61C5EE@employees.org> <35B57831-F31C-40D9-A34A-9469261F3636@employees.org> <50814AB3.9070307@cisco.com> <2D7C2D36-D308-4480-8858-9F5EF23EDC06@nominum.com> <50817BA9.6020503@cisco.com> <50824F32.1090602@cisco.com> <4DDC6ED5-C2FC-43A8-93D0-E06751D 67FB9@employees.org> <1EAF4610-FCE9-4DC0-B932-8DA1A3B34325@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1498) Cc: DHCP discussion list Subject: Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-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, 20 Oct 2012 16:47:06 -0000 >> by creating an application specific tunnel of IPv4 over IPv6. is = _that_ what we want to do? >=20 > Where is this tunnel of which you speak? that is effectively what DHCPv4 over IPv6 is. >> not sure I grok this question. the mechanism is that a MAP capable = CPE includes the MAP option in an ORO option. the DHCPv6 reply contains = e.g. the IPv4 address and port range and that IPv4 address and port = range is "assigned" to the outside of the NAT44 function. note, that it = is not and MUST NOT be assigned to an interface. so the normal IPv4 = allocation mechanism cannot be used. >> if this was based on the existing DHCPv4 address option, how would a = client know that the above restriction applies? >=20 > What allocation mechanism _is_ used? whatever policy the DHCP server has. can you answer my question please? cheers, Ole= From Ted.Lemon@nominum.com Sat Oct 20 11:14:11 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1550A21F8480 for ; Sat, 20 Oct 2012 11:14:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.35 X-Spam-Level: X-Spam-Status: No, score=-106.35 tagged_above=-999 required=5 tests=[AWL=-0.051, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 0+nCxu-zxuh4 for ; Sat, 20 Oct 2012 11:14:10 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 588E221F896F for ; Sat, 20 Oct 2012 11:14:10 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKUILp8eJmGQsrp5Ot/HclOLo/U/tmuZyQ@postini.com; Sat, 20 Oct 2012 11:14:10 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 4505B1B82A0 for ; Sat, 20 Oct 2012 11:14:09 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 31F5A19005C; Sat, 20 Oct 2012 11:14:09 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Sat, 20 Oct 2012 11:13:56 -0700 From: Ted Lemon To: =?Windows-1252?Q?Ole_Tr=F8an?= Thread-Topic: [dhcwg] Call for adoption: draft-sun-dhc-port-set-option Thread-Index: AQHNput68Hhly3n5akOtNZsf4t9jOpe/NbeAgABWX4CAAARBgIAAAb6AgAABPwCAAAUAAIAAARwAgAAMdICAAAMNAIABJiyAgAAWt4CAADARgIAAIF4AgAAaAICAAPhfAIAAA8wAgAAHU4CAABO1gIAAaOWAgAAcNQCAABhGgA== Date: Sat, 20 Oct 2012 18:13:56 +0000 Message-ID: <3D3DC439-7976-43A4-8976-2E5A34BDB0A5@nominum.com> References: <9D3C0AC1-D5B1-4C25-AC47-4D08E3252D54@nominum.com> <50800059.3030503@viagenie.ca> <4E18E4F4-7E60-41F7-8700-83EF2CF1D4A4@employees.org> <219448E3-6A90-411D-A430-EDE011E5E75E@nominum.com> <50F411F4-D3C5-4CED-B9BD-5E552C61C5EE@employees.org> <35B57831-F31C-40D9-A34A-9469261F3636@employees.org> <50814AB3.9070307@cisco.com> <2D7C2D36-D308-4480-8858-9F5EF23EDC06@nominum.com> <50817BA9.6020503@cisco.com> <50824F32.1090602@cisco.com> <4DDC6ED5-C2FC-43A8-93D0-E06751D 67FB9@employees.org> <1EAF4610-FCE9-4DC0-B932-8DA1A3B34325@nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <9889889181DF254292F192DB36CAE1AC@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: DHCP discussion list Subject: Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-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, 20 Oct 2012 18:14:11 -0000 On Oct 20, 2012, at 12:47 PM, Ole Tr=F8an wrote: > that is effectively what DHCPv4 over IPv6 is. Well, sure, in the same sense that the DHCP relay agent is effectively a tu= nnel. But it's consistent with the existing DHCP protocol, and calling it= a tunnel is only accurate in the most tortured interpretation of what a tu= nnel is. You could also call it a proxy; in fact, though, what it is in D= HCP terminology is simply a relay agent. Using an IPv6 transport for DHC = relay is a fairly minor innovation. Also, the chairs of softwires have in= formed me that in fact softwires _does_ support the DHCPv4-over-IPv6 work, = so this question is moot. >=20 >>> not sure I grok this question. the mechanism is that a MAP capable CPE = includes the MAP option in an ORO option. the DHCPv6 reply contains e.g. th= e IPv4 address and port range and that IPv4 address and port range is "assi= gned" to the outside of the NAT44 function. note, that it is not and MUST = NOT be assigned to an interface. so the normal IPv4 allocation mechanism ca= nnot be used. >>> if this was based on the existing DHCPv4 address option, how would a cl= ient know that the above restriction applies? >>=20 >> What allocation mechanism _is_ used? >=20 > whatever policy the DHCP server has. Okay, what policies could a DHCP server have? Have you documented these p= olicies? > can you answer my question please? A DHCPv4 client that supports the port set option has to request it. If i= t requests it, that means that it knows not to just use the IP address=97it= has to do A+P NAT44. So the _only_ client that can ever get an address a= nd port set pair is one that indicates it knows how to handle it properly. = Other clients would either be configured with a whole IPv4 address, or el= se would not receive an IPv4 address at all. From otroan@employees.org Sat Oct 20 12:53:31 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 839A721F88FF for ; Sat, 20 Oct 2012 12:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.268 X-Spam-Level: X-Spam-Status: No, score=-10.268 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 VCORyL2zblLY for ; Sat, 20 Oct 2012 12:53:31 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id AAB7121F887D for ; Sat, 20 Oct 2012 12:53:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,622,1344211200"; d="scan'208";a="77625054" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 20 Oct 2012 19:53:29 +0000 Received: from [10.61.101.100] (dhcp-10-61-101-100.cisco.com [10.61.101.100]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9KJrT5d006545 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 20 Oct 2012 19:53:29 GMT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: =?windows-1252?Q?Ole_Tr=F8an?= In-Reply-To: <3D3DC439-7976-43A4-8976-2E5A34BDB0A5@nominum.com> Date: Sat, 20 Oct 2012 21:53:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9E57F2F7-8FE0-4FBF-8F53-9C04EED8C224@employees.org> References: <9D3C0AC1-D5B1-4C25-AC47-4D08E3252D54@nominum.com> <50800059.3030503@viagenie.ca> <4E18E4F4-7E60-41F7-8700-83EF2CF1D4A4@employees.org> <219448E3-6A90-411D-A430-EDE011E5E75E@nominum.com> <50F411F4-D3C5-4CED-B9BD-5E552C61C5EE@employees.org> <35B57831-F31C-40D9-A34A-9469261F3636@employees.org> <50814AB3.9070307@cisco.com> <2D7C2D36-D308-4480-8858-9F5EF23EDC06@nominum.com> <50817BA9.6020503@cisco.com> <50824F32.1090602@cisco.com> <4DDC6ED5-C2FC-43A8-93D0-E06751D 67FB9@employees.org> <1EAF4610-FCE9-4DC0-B932-8DA1A3B34325@nominum.com> <3D3DC439-7976-43A4-8976-2E5A34BDB0A5@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1498) Cc: DHCP discussion list Subject: Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-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, 20 Oct 2012 19:53:31 -0000 Ted, >> that is effectively what DHCPv4 over IPv6 is. >=20 > Well, sure, in the same sense that the DHCP relay agent is effectively = a tunnel. But it's consistent with the existing DHCP protocol, and = calling it a tunnel is only accurate in the most tortured interpretation = of what a tunnel is. You could also call it a proxy; in fact, though, = what it is in DHCP terminology is simply a relay agent. Using an IPv6 = transport for DHC relay is a fairly minor innovation. Also, the chairs = of softwires have informed me that in fact softwires _does_ support the = DHCPv4-over-IPv6 work, so this question is moot. this work exists within a larger context. e.g. how does a client know that it should act as a relay? >>>> not sure I grok this question. the mechanism is that a MAP capable = CPE includes the MAP option in an ORO option. the DHCPv6 reply contains = e.g. the IPv4 address and port range and that IPv4 address and port = range is "assigned" to the outside of the NAT44 function. note, that it = is not and MUST NOT be assigned to an interface. so the normal IPv4 = allocation mechanism cannot be used. >>>> if this was based on the existing DHCPv4 address option, how would = a client know that the above restriction applies? >>>=20 >>> What allocation mechanism _is_ used? >>=20 >> whatever policy the DHCP server has. >=20 > Okay, what policies could a DHCP server have? Have you documented = these policies? what are you asking about? I have no intention of documenting allocation = policy. why should the IETF do that? >> can you answer my question please? >=20 > A DHCPv4 client that supports the port set option has to request it. = If it requests it, that means that it knows not to just use the IP = address=97it has to do A+P NAT44. So the _only_ client that can ever = get an address and port set pair is one that indicates it knows how to = handle it properly. Other clients would either be configured with a = whole IPv4 address, or else would not receive an IPv4 address at all. so you are saying that based on this option, a DHCPv4 client must act = quite differently in how it uses the information in the address option = compared to if this option is not present. in the proposed DHCPv6 = option, both the port set and the address is within one container = option, that is specifically for this purpose. it doesn't give a legacy = option a new meaning. as Eliot suggests I think it is more fruitful to do this discussion IRL. cheers, Ole From Ted.Lemon@nominum.com Sat Oct 20 14:10:12 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85F6A21F89BF for ; Sat, 20 Oct 2012 14:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.349 X-Spam-Level: X-Spam-Status: No, score=-106.349 tagged_above=-999 required=5 tests=[AWL=-0.051, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 uK+S501C09uJ for ; Sat, 20 Oct 2012 14:10:11 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 0469E21F8980 for ; Sat, 20 Oct 2012 14:10:10 -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 DSNKUIMTMmpVBshMNS2HW4Kckj3xvpZFx+c5@postini.com; Sat, 20 Oct 2012 14:10: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 F41781B829C for ; Sat, 20 Oct 2012 14:10:09 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 87D5619005C; Sat, 20 Oct 2012 14:10:09 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Sat, 20 Oct 2012 14:10:09 -0700 From: Ted Lemon To: =?Windows-1252?Q?Ole_Tr=F8an?= Thread-Topic: [dhcwg] Call for adoption: draft-sun-dhc-port-set-option Thread-Index: AQHNput68Hhly3n5akOtNZsf4t9jOpe/NbeAgABWX4CAAARBgIAAAb6AgAABPwCAAAUAAIAAARwAgAAMdICAAAMNAIABJiyAgAAWt4CAADARgIAAIF4AgAAaAICAAPhfAIAAA8wAgAAHU4CAABO1gIAAaOWAgAAcNQCAABhGgIAAG9EAgAAVawA= Date: Sat, 20 Oct 2012 21:10:09 +0000 Message-ID: <50F98AE9-A285-4309-995E-FB7D3C5EC803@nominum.com> References: <9D3C0AC1-D5B1-4C25-AC47-4D08E3252D54@nominum.com> <50800059.3030503@viagenie.ca> <4E18E4F4-7E60-41F7-8700-83EF2CF1D4A4@employees.org> <219448E3-6A90-411D-A430-EDE011E5E75E@nominum.com> <50F411F4-D3C5-4CED-B9BD-5E552C61C5EE@employees.org> <35B57831-F31C-40D9-A34A-9469261F3636@employees.org> <50814AB3.9070307@cisco.com> <2D7C2D36-D308-4480-8858-9F5EF23EDC06@nominum.com> <50817BA9.6020503@cisco.com> <50824F32.1090602@cisco.com> <4DDC6ED5-C2FC-43A8-93D0-E06751D 67FB9@employees.org> <1EAF4610-FCE9-4DC0-B932-8DA1A3B34325@nominum.com> <3D3DC439-7976-43A4-8976-2E5A34BDB0A5@nominum.com> <9E57F2F7-8FE0-4FBF-8F53-9C04EED8C224@employees.org> In-Reply-To: <9E57F2F7-8FE0-4FBF-8F53-9C04EED8C224@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_50F98AE9A2854309995EFB7D3C5EC803nominumcom_" MIME-Version: 1.0 Cc: DHCP discussion list Subject: Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-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, 20 Oct 2012 21:10:12 -0000 --_000_50F98AE9A2854309995EFB7D3C5EC803nominumcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Oct 20, 2012, at 3:53 PM, Ole Tr=F8an > wrote: e.g. how does a client know that it should act as a relay? The DHCPv6 server sends it a DHCPv4-over-IPv6 CRA IPv6 Address option. what are you asking about? I have no intention of documenting allocation po= licy. why should the IETF do that? This is my point. You are claiming to provide the functionality of a DHCP= v4 server, but your draft leaves that as an exercise for the reader. IOW,= it's not a complete solution. If the policy happens to be a simple trans= formation from IPv6 to IPv4 address, then this is probably fine, but it's n= ot solving the same problem that the DHC working group is solving with the = DHCPv4-over-IPv6 draft and this draft. so you are saying that based on this option, a DHCPv4 client must act quite= differently in how it uses the information in the address option compared = to if this option is not present. in the proposed DHCPv6 option, both the p= ort set and the address is within one container option, that is specificall= y for this purpose. it doesn't give a legacy option a new meaning. You seem to be stating this as if it is an advantage, but it's not clear to= me how that would be so, or even what "legacy option" you are talking abou= t. Either way: * information is delivered to the device (typically a CPE device) and i= t sets up an A+P configuration with NAT * it is not easier to do this via DHCPv6 than DHCPv4 * doing it via DHCPv6 has implications for the DHCPv6 server that you a= re addressing with a handwave * placing the burden of implementation on the DHCPv4 client is no worse= than placing it on the DHCPv6 client, except that the DHCPv4 client is goi= ng away, and the DHCPv6 client is not * placing the burden of implementation on the DHCPv6 server is no bette= r than placing it on the DHCPv4 server, except that the DHCPv4 server is go= ing away, and the DHCPv6 server is not. So in certain cases, the DHCPv6-based solution will in fact work just fine,= with minimal negative impact. However, the DHCPv4-over-IPv6 solution wil= l work well in all cases, with zero negative impact. No changes are requi= red anywhere except on the DHCPv4 server and the CPE device (or whatever de= vice is doing A+P). This is why the DHC working group chose that solution= . as Eliot suggests I think it is more fruitful to do this discussion IRL. We can certainly try to get some clarity on the topic, but the business of = the IETF is transacted on the mailing lists, not in person. --_000_50F98AE9A2854309995EFB7D3C5EC803nominumcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable On Oct 20, 2012, at 3:53 PM, Ole Tr=F8an <otroan@employees.org>
 wrote:
e.g. how does a client know that it should act as= a relay?

The DHCPv6 server sends it a DHCPv4-over-IPv6 CRA IPv6 Address option.=

what are you asking about? I have no intention of= documenting allocation policy. why should the IETF do that?

This is my point.   You are claiming to provide the functionality= of a DHCPv4 server, but your draft leaves that as an exercise for the read= er.   IOW, it's not a complete solution.   If the policy happens = to be a simple transformation from IPv6 to IPv4 address, then this is probably fine, but it's not solving the same problem= that the DHC working group is solving with the DHCPv4-over-IPv6 draft and = this draft.

so you are saying that based on this option, a DH= CPv4 client must act quite differently in how it uses the information = in the address option compared to if this option is not present. in the pro= posed DHCPv6 option, both the port set and the address is within one container option, that is specifically for t= his purpose. it doesn't give a legacy option a new meaning.
You seem to be stating this as if it is an advantage, but it's not cle= ar to me how that would be so, or even what "legacy option" you a= re talking about.   Either way:

  • information is delivered to the device (typically a CPE device) and it = sets up an A+P configuration with NAT
  • it is not easier to do th= is via DHCPv6 than DHCPv4
  • doing it via DHCPv6 has implications for = the DHCPv6 server that you are addressing with a handwave
  • placing t= he burden of implementation on the DHCPv4 client is no worse than placing i= t on the DHCPv6 client, except that the DHCPv4 client is going away, and th= e DHCPv6 client is not
  • placing the burden of implementation on the = DHCPv6 server is no better than placing it on the DHCPv4 server, except tha= t the DHCPv4 server is going away, and the DHCPv6 server is not.

So in certain cases, the DHCPv6-based solution will in fact work just = fine, with minimal negative impact.   However, the DHCPv4-over-IPv6 so= lution will work well in all cases, with zero negative impact.   No ch= anges are required anywhere except on the DHCPv4 server and the CPE device (or whatever device is doing A+P). &n= bsp; This is why the DHC working group chose that solution.

as Eliot suggests I think it is more fruitful to = do this discussion IRL.

We can certainly try to get some clarity on the topic, but the busines= s of the IETF is transacted on the mailing lists, not in person.
--_000_50F98AE9A2854309995EFB7D3C5EC803nominumcom_-- From elear@cisco.com Sat Oct 20 14:23:55 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB3B21F86C8 for ; Sat, 20 Oct 2012 14:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.765 X-Spam-Level: X-Spam-Status: No, score=-9.765 tagged_above=-999 required=5 tests=[AWL=0.833, 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 HwJ+IvDxzw4q for ; Sat, 20 Oct 2012 14:23:54 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id C7BCB21F846F for ; Sat, 20 Oct 2012 14:23:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1579; q=dns/txt; s=iport; t=1350768234; x=1351977834; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=EthNrgMHG/m3PhL0NVYqPrqqNlw9S+INGKKSjbrqbnM=; b=Q9r9rUDwoVpxPWbgHxLFf6LWkw8Nyxh7+tboAxaOBlR14xa7gQsf1AH8 wgOGYKDOMBl4INNoic9/e29Nj5e1DU4C0RwXqVcHIfGVk/ldc0ad34kU+ EgGhu06f7KUsA3k5s8xpLJWfMQavVhyvye21swC0e83z4Vu3EkCyWp1mf Y=; X-IronPort-AV: E=Sophos;i="4.80,622,1344211200"; d="scan'208,217";a="133744030" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-6.cisco.com with ESMTP; 20 Oct 2012 21:23:54 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q9KLNsK9010824 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 20 Oct 2012 21:23:54 GMT Received: from xmb-rcd-x11.cisco.com ([169.254.1.131]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.001; Sat, 20 Oct 2012 16:23:53 -0500 From: "Eliot Lear (elear)" To: Ted Lemon Thread-Topic: [dhcwg] Call for adoption: draft-sun-dhc-port-set-option Thread-Index: AQHNput68Hhly3n5akOtNZsf4t9jOpe/NbeAgABWX4CAAARBgIAAAb6AgAABPwCAAAUAAIAAARwAgAAMdICAAAMNAIABJiyAgAAWt4CAADARgIAAIF4AgAAaAICAAPhfAIAAA8wAgAAHU4CAABO1gIAAaOWA///6rgCAABhHAIAAG9AAgAAVbID//7AFmw== Date: Sat, 20 Oct 2012 21:23:53 +0000 Message-ID: <9A8AB174-974A-4C85-9149-313A54CD4761@cisco.com> References: <9D3C0AC1-D5B1-4C25-AC47-4D08E3252D54@nominum.com> <50800059.3030503@viagenie.ca> <4E18E4F4-7E60-41F7-8700-83EF2CF1D4A4@employees.org> <219448E3-6A90-411D-A430-EDE011E5E75E@nominum.com> <50F411F4-D3C5-4CED-B9BD-5E552C61C5EE@employees.org> <35B57831-F31C-40D9-A34A-9469261F3636@employees.org> <50814AB3.9070307@cisco.com> <2D7C2D36-D308-4480-8858-9F5EF23EDC06@nominum.com> <50817BA9.6020503@cisco.com> <50824F32.1090602@cisco.com> <4DDC6ED5-C2FC-43A8-93D0-E06751D 67FB9@employees.org> <1EAF4610-FCE9-4DC0-B932-8DA1A3B34325@nominum.com> <3D3DC439-7976-43A4-8976-2E5A34BDB0A5@nominum.com> <9E57F2F7-8FE0-4FBF-8F53-9C04EED8C224@employees.org>, <50F98AE9-A285-4309-995E-FB7D3C5EC803@nominum.com> In-Reply-To: <50F98AE9-A285-4309-995E-FB7D3C5EC803@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19290.004 x-tm-as-result: No--26.741800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_9A8AB174974A4C859149313A54CD4761ciscocom_" MIME-Version: 1.0 X-Mailman-Approved-At: Sat, 20 Oct 2012 19:54:49 -0700 Cc: DHCP discussion list Subject: Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-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, 20 Oct 2012 21:23:55 -0000 --_000_9A8AB174974A4C859149313A54CD4761ciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ted, as Eliot suggests I think it is more fruitful to do this discussion IRL. We can certainly try to get some clarity on the topic, but the business of = the IETF is transacted on the mailing lists, not in person. The point is to use a high bandwidth medium that is expressly set for such = occasions, a f2f meeting. It's not as if one has to wait so long... Eliot --_000_9A8AB174974A4C859149313A54CD4761ciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Ted,

as Eliot suggests I think it is more fruitful to = do this discussion IRL.

We can certainly try to get some clarity on the topic, but the busines= s of the IETF is transacted on the mailing lists, not in person.

The point is to use a high bandwidth medium that is expressly set for = such occasions, a f2f meeting. It's not as if one has to wait so long...

Eliot
--_000_9A8AB174974A4C859149313A54CD4761ciscocom_-- From internet-drafts@ietf.org Sun Oct 21 19:30:22 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCCCB21F8422; Sun, 21 Oct 2012 19:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.521 X-Spam-Level: X-Spam-Status: No, score=-102.521 tagged_above=-999 required=5 tests=[AWL=0.078, 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 xYUdwAA4eNUd; Sun, 21 Oct 2012 19:30:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC0721F8428; Sun, 21 Oct 2012 19:30:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121022023022.31796.83986.idtracker@ietfa.amsl.com> Date: Sun, 21 Oct 2012 19:30:22 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-03.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 02:30:23 -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 Group = of the IETF. Title : RADIUS Option for DHCPv6 Relay Agents on Broadband Acces= s Server Author(s) : Leaf Y. Yeh Mohamed Boucadair Ted Lemon Filename : draft-ietf-dhc-dhcpv6-radius-opt-03.txt Pages : 9 Date : 2012-10-21 Abstract: The DHCPv6 RADIUS option provides a mechanism to exchange authorization and identification information between relay agent and server. This mechanism is meant to the centralized DHCPv6 server to select the right configuration for the requesting client based on the authorization information received from the RADIUS server, which is not co-located with the DHCPv6 server. The NAS acts as DHCPv6 relay agent and RADIUS client simultaneously in this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-radius-opt There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-radius-opt-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-dhcpv6-radius-opt-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From leaf.y.yeh@huawei.com Sun Oct 21 19:41:01 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77FD921F8A38 for ; Sun, 21 Oct 2012 19:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.491 X-Spam-Level: X-Spam-Status: No, score=-6.491 tagged_above=-999 required=5 tests=[AWL=0.108, 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 bB3jMTGLzhn5 for ; Sun, 21 Oct 2012 19:41:00 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3687521F8A21 for ; Sun, 21 Oct 2012 19:41:00 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKU85130; Mon, 22 Oct 2012 02:40:59 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 22 Oct 2012 03:40:55 +0100 Received: from SZXEML424-HUB.china.huawei.com (10.82.67.163) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 22 Oct 2012 03:40:58 +0100 Received: from SZXEML546-MBX.china.huawei.com ([169.254.3.157]) by szxeml424-hub.china.huawei.com ([10.82.67.163]) with mapi id 14.01.0323.003; Mon, 22 Oct 2012 10:40:51 +0800 From: Leaf yeh To: "dhcwg@ietf.org" Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-03.txt Thread-Index: AQHNr/1HNSd5KF2CtUyzfSel6RTWmJfEmrcQ Date: Mon, 22 Oct 2012 02:40:50 +0000 Message-ID: References: <20121022023022.31796.83986.idtracker@ietfa.amsl.com> In-Reply-To: <20121022023022.31796.83986.idtracker@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.83.152] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "Bernie Volz \(volz\)" , Tomek Mrugalski Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-03.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 02:41:01 -0000 Dear folks, Supposed it is ready for your thorough review again. Your further comments = are more than welcome. :-) BTW, there is no meaningful change from ver.-02 to ver.-03, just some expre= ssion in text. But there has some changes from ver.-01 to ver.-02. Best Regards, Leaf -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of i= nternet-drafts@ietf.org Sent: Monday, October 22, 2012 10:30 AM To: i-d-announce@ietf.org Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-03.txt 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 Group = of the IETF. Title : RADIUS Option for DHCPv6 Relay Agents on Broadband Acces= s Server Author(s) : Leaf Y. Yeh Mohamed Boucadair Ted Lemon Filename : draft-ietf-dhc-dhcpv6-radius-opt-03.txt Pages : 9 Date : 2012-10-21 Abstract: The DHCPv6 RADIUS option provides a mechanism to exchange authorization and identification information between relay agent and server. This mechanism is meant to the centralized DHCPv6 server to select the right configuration for the requesting client based on the authorization information received from the RADIUS server, which is not co-located with the DHCPv6 server. The NAS acts as DHCPv6 relay agent and RADIUS client simultaneously in this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-radius-opt There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-radius-opt-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-dhcpv6-radius-opt-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From ghalwasi@cisco.com Mon Oct 22 00:01:57 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37FF221F8442 for ; Mon, 22 Oct 2012 00:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.162 X-Spam-Level: X-Spam-Status: No, score=-10.162 tagged_above=-999 required=5 tests=[AWL=0.437, 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 3SgYe7Bua4P1 for ; Mon, 22 Oct 2012 00:01:56 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 2436421F842C for ; Mon, 22 Oct 2012 00:01:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3745; q=dns/txt; s=iport; t=1350889302; x=1352098902; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=iFsTafrRoK5oGgOHnIvlqZx/CwePQSrNWW2++8gIvWg=; b=C5dIyRr0x5ymIv6lCbUUPdS3G+LTeYiLdM8cN91SdmBASeKsPUskiYA9 B1rk2+uJhHzrXHSu/D6jBdyC0pNyILhoUHF+rr8owbL6uBuIgMi2CPoR5 fkAcGtoa2xkn1MdNGkDctg9jpgzIrWIaNl0zpcylUY1/ErGq8JoRXSj7z Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALvuhFCtJV2Y/2dsb2JhbABFwQuBCIIgAQEBBAEBAQ8BJzQLDAQCAQgRBAEBCxQJBycLFAkIAgQBDQUIARmHYgubTp8Wi1+GD2ADlwiNN4Frgm+CGA X-IronPort-AV: E=Sophos;i="4.80,628,1344211200"; d="scan'208";a="134005519" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP; 22 Oct 2012 07:01:41 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9M71fgI021536 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Oct 2012 07:01:41 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.220]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.001; Mon, 22 Oct 2012 02:01:41 -0500 From: "Gaurav Halwasia (ghalwasi)" To: Leaf yeh , "dhcwg@ietf.org" Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-03.txt Thread-Index: AQHNr/1GDp5inQDbOkmGgNRDgWCa/pfE8SIA///wfyA= Date: Mon, 22 Oct 2012 07:01:41 +0000 Message-ID: <90903C21C73202418A48BFBE80AEE5EB1BD89EEA@xmb-aln-x06.cisco.com> References: <20121022023022.31796.83986.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.142.105.234] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19294.004 x-tm-as-result: No--36.020200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Bernie Volz \(volz\)" , Tomek Mrugalski Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-03.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 07:01:57 -0000 Hi Leaf, This is a useful work and I do support this work. I have few comments thoug= h. * Abstract says, " This mechanism is meant to the centralized DHCPv6 server= to select the right configuration for the requesting client ... ". Does no= t it say " This mechanism is meant for the centralized DHCPv6 server .." .? * Section 4 heading could say "DHCPv6 OPTION_RADIUS option" * Section 4 says, " only the attributes listed in the table below may be in= cluded in the OPTION_RADIUS ". What about any other attributes which might = be required in future.? Are you suggesting that a new specification will be= required to include any other attribute in DHCPv6 RADIUS_OPTION option.? I= MO, keeping the attribute list open for the implementer will increase the = usability of this mechanism. I think this specification can just mention th= e attributes as one of the use-case.=20 * Section 5, "Relay Agent Behavior" says " The relay agent MUST silently di= scard OPTION_RADIUS if received. ". Can you explain about it little more and what is your pr= oposal keeping "Relay Chaining" in mind.? Thanks, Gaurav -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of L= eaf yeh Sent: Monday, October 22, 2012 8:11 AM To: dhcwg@ietf.org Cc: Bernie Volz (volz); Tomek Mrugalski Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-03.txt Dear folks, Supposed it is ready for your thorough review again. Your further comments = are more than welcome. :-) BTW, there is no meaningful change from ver.-02 to ver.-03, just some expre= ssion in text. But there has some changes from ver.-01 to ver.-02. Best Regards, Leaf -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of i= nternet-drafts@ietf.org Sent: Monday, October 22, 2012 10:30 AM To: i-d-announce@ietf.org Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-03.txt 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 Group = of the IETF. Title : RADIUS Option for DHCPv6 Relay Agents on Broadband Acces= s Server Author(s) : Leaf Y. Yeh Mohamed Boucadair Ted Lemon Filename : draft-ietf-dhc-dhcpv6-radius-opt-03.txt Pages : 9 Date : 2012-10-21 Abstract: The DHCPv6 RADIUS option provides a mechanism to exchange authorization and identification information between relay agent and server. This mechanism is meant to the centralized DHCPv6 server to select the right configuration for the requesting client based on the authorization information received from the RADIUS server, which is not co-located with the DHCPv6 server. The NAS acts as DHCPv6 relay agent and RADIUS client simultaneously in this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-radius-opt There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-radius-opt-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-dhcpv6-radius-opt-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ 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 Mon Oct 22 03:41:36 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD17521F8B6C; Mon, 22 Oct 2012 03:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.068, 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 r+LXAQuBP29u; Mon, 22 Oct 2012 03:41:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 313C521F89EC; Mon, 22 Oct 2012 03:41:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121022104136.7949.92089.idtracker@ietfa.amsl.com> Date: Mon, 22 Oct 2012 03:41:36 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-prefix-pool-opt-01.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, 22 Oct 2012 10:41:37 -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 Group = of the IETF. Title : Prefix Pool Option for DHCPv6 Relay Agents on Provider E= dge Routers Author(s) : Leaf Y. Yeh Ted Lemon Mohamed Boucadair Filename : draft-ietf-dhc-dhcpv6-prefix-pool-opt-01.txt Pages : 13 Date : 2012-10-22 Abstract: The DHCPv6 Prefix Pool option provides a mechanism for DHCPv6 Prefix Delegation (DHCPv6-PD), allowing the DHCPv6 server to notify a DHCPv6 relay agent implemented on a Provider Edge (PE) router about active prefix pools allocated by the DHCPv6 server to the PE router. The information of active prefix pools can be used to enforce IPv6 route aggregation on the PE router through adding or removing aggregation routes according to the status of the prefix pools. The advertising of the aggregation routes in the routing protocol enabled on the network-facing interface of PE routers will dramatically decreases the number of the routing table entries in the ISP network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-prefix-pool-opt There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-prefix-pool-opt-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-dhcpv6-prefix-pool-opt-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From yangtianle@chinamobile.com Mon Oct 22 04:25:19 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D434D21F8AE0 for ; Mon, 22 Oct 2012 04:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.711 X-Spam-Level: *** X-Spam-Status: No, score=3.711 tagged_above=-999 required=5 tests=[AWL=1.687, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_83=0.6, J_CHICKENPOX_84=0.6, RELAY_IS_221=2.222] 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 HanZKAEmo63Y for ; Mon, 22 Oct 2012 04:25:18 -0700 (PDT) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 761CD21F897F for ; Mon, 22 Oct 2012 04:25:17 -0700 (PDT) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 50A7BE570 for ; Mon, 22 Oct 2012 19:25:18 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 3FC10E55F for ; Mon, 22 Oct 2012 19:25:18 +0800 (CST) Received: from yangtianle ([10.2.43.97]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012102219251536-22572 ; Mon, 22 Oct 2012 19:25:15 +0800 From: "yangtianle" To: Date: Mon, 22 Oct 2012 19:25:03 +0800 Message-ID: <008901cdb047$e142cb30$a3c86190$@com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2wQ9LTuZk0N1otQZyIh2pHZhBYdQAA/7Pg X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-10-22 19:25:15, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-10-22 19:25:17 Content-Type: multipart/mixed; boundary="----=_NextPart_000_008A_01CDB08A.EF660B30" Content-Language: zh-cn X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-19294.006 X-TM-AS-Result: No--27.350-7.0-31-10 X-imss-scan-details: No--27.350-7.0-31-10;No--27.350-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No;No Subject: [dhcwg] IPv6 Transition Technologies Selection using DHCP/DHCPv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 11:25:19 -0000 ------=_NextPart_000_008A_01CDB08A.EF660B30 Content-Type: multipart/alternative; boundary="----=_NextPart_001_008B_01CDB08A.EF660B30" ------=_NextPart_001_008B_01CDB08A.EF660B30 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="gb2312" =20 _____ =20 From: yangtianle@hotmail.com To: dhcwg@ietf.org Subject: IPv6 Transition Technologies Selection using DHCP/DHCPv6 Date: Mon, 22 Oct 2012 18:38:28 +0800 Hi, all, =20 We find some inconvenient issues about CPE when we do IPv6 trials and experiments:=20 1=A1=A2ISP must pre-configure IPv6 transition technology in = CPE, such as dual-stack, DS-Lite, and so on. 2=A1=A2Otherwise, ISP must rely on Manage System to control = CPEs. But if CPEs are form different manufactories, they need different Manage = System, or to develop consistent interface in the Manage System. 3=A1=A2If users change the CPE ISP giving to them to another = one with incorrect configuration, or configure CPE incorrectly by mistake, they cannot access internet.=20 =20 In this document, we propose a solution to solve the problem. Although = this draft is submitted in WG v6ops, the solution is DHCP/DHCPv6. Here is the draft: http://tools.ietf.org/html/draft-yang-v6ops-ipv6tran-select =20 Wish for your comments. Thank you! =20 Tianle Yang =20 =20 =20 ------=_NextPart_001_008B_01CDB08A.EF660B30 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="gb2312"

 

From: yangtianle@hotmail.com
To: dhcwg@ietf.org
Subject: IPv6 Transition Technologies Selection using DHCP/DHCPv6
Date: Mon, 22 Oct 2012 18:38:28 +0800

Hi, all,

 =

We find some inconvenient issues about CPE when we do IPv6 trials and = experiments: =

    &nbs= p;    1=A1=A2ISP must pre-configure IPv6 transition technology in CPE, such as dual-stack, = DS-Lite, and so on.=

    &nbs= p;    2=A1=A2Otherwise, ISP must rely on Manage System to control CPEs. But if CPEs are form = different manufactories, they need different Manage System, or to develop = consistent interface in the Manage System.

    &nbs= p;    3=A1=A2If users change the CPE ISP giving to them to another one with incorrect = configuration, or configure CPE incorrectly by mistake, they cannot access internet. = =

 =

In this document, we propose a solution to solve the problem. Although this = draft is submitted in WG v6ops, the solution is DHCP/DHCPv6.=

Here is the draft:=

http://tools.ietf.org/html/draft-yang-v6ops-ipv6tran-se= lect

 =

Wish for your comments. Thank you!

 =

Tianle Yang=

 
 

 

------=_NextPart_001_008B_01CDB08A.EF660B30-- ------=_NextPart_000_008A_01CDB08A.EF660B30 Content-Type: text/plain; name="draft-yang-v6ops-ipv6tran-select-00.txt" Content-Disposition: attachment; filename="draft-yang-v6ops-ipv6tran-select-00.txt" Content-Transfer-Encoding: quoted-printable =0A=0A=0AInternet Engineering Task Force T= . Yang=0AInternet-Draft = L. Li=0AIntended status: Standards Track = Q. Ma=0AExpires: April 15, 2013 China = Mobile=0A Oct 12= , 2012=0A=0A=0A IPv6 Transition Technologies Selection using DHCP/DH= CPv6=0A draft-yang-v6ops-IPv6tran-select-00=0A=0AAbstract= =0A=0A Nowadays, many IPv6 transition technologies has been proposed, suc= h=0A as Dual-Stack, DS-Lite, 6rd and so on. An CPE may support some of= =0A them instead of only one. But ISPs usually deploy just an unique=0A = transition technology in an area, for example, under a BRAS/SR or in=0A = a MAN. So they must control all the CPEs to ues the exact transition=0A = tech through the CPEs' management system or configuring them before=0A i= ssuing to the customers. Another question is that if subscriber buy=0A a= new CPE from supermarket to substitute the one received from the=0A ISP,= he may not access internet because of the wrong configuration.=0A=0A To = solve these problems,this document defines a new DHCP/DHCPv6=0A option na= med TRAN=5FTYPE which can control CPEs to select the=0A appropriate IPv6 = transition technology which ISP deployed instend of=0A the CPEs' default = configration. This method can also solve the=0A configurating problem wh= en various CPEs work together without a=0A uniform configuration in advan= ce.=0A=0AStatus of this Memo=0A=0A This Internet-Draft is submitted to IE= TF in full conformance with the=0A provisions of BCP 78 and BCP 79.=0A=0A= Internet-Drafts are working documents of the Internet Engineering=0A T= ask Force (IETF). Note that other groups may also distribute=0A working = documents as Internet-Drafts. The list of current Internet-=0A Drafts is= at http://datatracker.ietf.org/drafts/current/.=0A=0A Internet-Drafts ar= e draft documents valid for a maximum of six months=0A and may be updated= , replaced, or obsoleted by other documents at any=0A time. It is inappr= opriate to use Internet-Drafts as reference=0A material or to cite them o= ther than as "work in progress."=0A=0A This Internet-Draft will expire on= April 15, 2013.=0A=0ACopyright Notice=0A=0A=0A=0A=0AYang, et al. = Expires April 15, 2013 [Page 1]=0A=0C=0AInternet-Draft = IPv6tran-select Oct 2012=0A=0A=0A Copyrig= ht (c) 2012 IETF Trust and the persons identified as the=0A document auth= ors. All rights reserved.=0A=0A This document is subject to BCP 78 and t= he IETF Trust's Legal=0A Provisions Relating to IETF Documents=0A (http= ://trustee.ietf.org/license-info) in effect on the date of=0A publication= of this document. Please review these documents=0A carefully, as they d= escribe your rights and restrictions with respect=0A to this document. C= ode Components extracted from this document must=0A include Simplified BS= D License text as described in Section 4.e of=0A the Trust Legal Provisio= ns and are provided without warranty as=0A described in the Simplified BS= D License.=0A=0A=0ATable of Contents=0A=0A 1. Introduction . . . . . . = . . . . . . . . . . . . . . . . . . . 3=0A 2. Requirements Language . . = . . . . . . . . . . . . . . . . . . . 3=0A 3. DHCP Solution . . . . . . = . . . . . . . . . . . . . . . . . . . 3=0A 4. DHCPv6 Solution . . . . . = . . . . . . . . . . . . . . . . . . . 5=0A 5. Other questions . . . . . = . . . . . . . . . . . . . . . . . . . 6=0A 6. Security Considerations . = . . . . . . . . . . . . . . . . . . . 6=0A 7. IANA Considerations . . . = . . . . . . . . . . . . . . . . . . . 6=0A 8. Refrences . . . . . . . . = . . . . . . . . . . . . . . . . . . . 7=0A Authors' Addresses . . . . . = . . . . . . . . . . . . . . . . . . . 7=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A= =0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0AYang, et al. Expir= es April 15, 2013 [Page 2]=0A=0C=0AInternet-Draft = IPv6tran-select Oct 2012=0A=0A=0A1. Introduction= =0A=0A Nowadays, many IPv6 transitioning technologies has been proposed s= uch=0A as Dual-Stack, DS-Lite, 6rd and so on. Each of them proposes=0A = individual requirment to the CPEs. To promote the competitive=0A abilit= y of products,the CPE manufacturers certainly will try to=0A support more= technologies as much as possible. Meanwhile, the=0A operators tend to u= se single or less technologies. Moreover, users=0A can buy and use their= own equipments instead of using the one which=0A operator gives them, th= at will bring the diversity of CPEs.=0A=0A Assume that an operator uses o= ne transitioning strategy in its=0A network. There are two ways to make = the CPEs available. The first=0A one is to make a pre-configuration for = each CPE in advance. But,=0A when the users modify the configuration or = change to their own=0A equipment, the connection will fail. The Second m= ethod is to deploy=0A Network Management System (NMS) to configurate all = the CPEs. Various=0A CPEs from different manufactories usually need diff= erent NMS which=0A means either the operator needs to maintains multiple = NMS in their=0A network or operator can only use one manufacturer's produ= ct in a=0A subnet. What's worse, when users buy and use their own CPE in= stead=0A of using the original one, there will be no any solutions to=0A = configurate correctly except visiting service.=0A=0A DHCP and DHCPv6 so= lutions are presented in this document to solve the=0A problem mentioned = above. By supporting this option, the operator can=0A configurate the CP= Es simple and directly by delivering DHCP or DHCPv6=0A options.=0A=0A=0A2= . Requirements Language=0A=0A The key words "MUST", "MUST NOT", "REQUIRE= D", "SHALL", "SHALL NOT",=0A "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY"= , and "OPTIONAL" in this=0A document are to be interpreted as described i= n [RFC2119].=0A=0A=0A3. DHCP Solution=0A=0A DHCP protocol will be used d= uring the configuration process of CPE in=0A IPoE scenario. Here, a new = option named OPTION=5FTRAN=5FTYPE is defined.=0A This option is sent by a= server to a CPE to affect the selection of=0A transition strategy by the= client.=0A=0A The format of the OPTION=5FTRAN=5FTYPE option is:=0A=0A=0A= =0A=0A=0A=0AYang, et al. Expires April 15, 2013 = [Page 3]=0A=0C=0AInternet-Draft IPv6tran-select = Oct 2012=0A=0A=0A 0 1 2 = 3=0A 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 = 5 6 7 8 9 0 1=0A +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+=0A | code | length | mode = |=0A +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+=0A=0A=0A Figure 1: OPTION=5FTRAN=5FTYPE=0A= =0A code OPTION=5FTRAN=5FTYPE (TBD).=0A=0A length 2.=0A=0A mode The v= alue for the transition technology.=0A=0A The process of this operation i= s:=0A=0A 1. The DHCP module in CPE broadcasts the Discover Message.=0A= =0A 2. The DHCP module in Server (such as BRAS/SR) replies the Offer=0A = Message.=0A=0A 3. CPE MUST send Request message with OPTION=5FTRAN=5FT= YPE option code=0A in option55[Parameter Request List, RFC2131,section 9.= 8] to Server.=0A=0A 4. Server replies ACK message with OPTION=5FTRA=5FTY= PE option to CPE,=0A which may allow or allocate a transition strategy (s= uch as mode =3D 1).=0A=0A A server MAY include a TRAN=5FTYPE option in an= y DHCP message to=0A control the transition strategy selection of the CPE= , including=0A Discover, Offer, Request, Reply, and Inform Messages.=0A= =0A The server can also send the OPTION=5FTRA=5FTYPE option in Offer Mess= age=0A or ACK Message directly without the request OPTION code in Discove= r=0A or Request Message from CPE.=0A=0A To avoid OPTION=5FTRAN=5FTYPE m= eanings ambiguity, the 'mode' field must=0A be consisitent in any CPE and= server. The list of all the transition=0A technologies must be defined = by IANA or other organizations. For=0A example, the 'mode' field list is= set as below.=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0AYang, et al. = Expires April 15, 2013 [Page 4]=0A=0C=0AInternet-Draft = IPv6tran-select Oct 2012=0A=0A=0A +-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A | mode | transition= tech. |=0A +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A | = 0 | Dual Stack |=0A +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+=0A | 1 | DS-Lite |=0A +-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A | 2 | ..= . ... |=0A +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=0A= =0A=0A Figure 2: meanings of mode field=0A=0A=0A4. DHC= Pv6 Solution=0A=0A In IPv6oE scenario, CPE must support DHCPv6 which can = be used during=0A the configuration process. As above, we can also defin= e a new option=0A named OPTION=5FTRAN=5FTYPE to unify the transition tech= nology of CPE and=0A server. This option is sent by a server to a CPE to= affect the=0A selection of transition strategy of the client.=0A=0A Th= e format of the OPTION=5FTRAN=5FTYPE option is:=0A=0A=0A 0 = 1 2 3=0A 0 1 2 3 4 5 6 7 8 = 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=0A +-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A | option-code = | option-len |=0A +-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A | mode = |=0A +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=0A=0A = Figure 3: OPTION=5FTRAN=5FTYPE=0A=0A option-code OPTION=5FTRAN=5FTYPE= (TBD).=0A=0A option-len 2.=0A=0A mode The value for the transition str= ategy.=0A=0A The process of this operation is:=0A=0A 1. The DHCPv6 mod= ule in CPE broadcasts the Solicit Message.=0A=0A 2. The DHCPv6 module in= Server (such as BRAS/SR) replies the=0A=0A=0A=0AYang, et al. E= xpires April 15, 2013 [Page 5]=0A=0C=0AInternet-Draft = IPv6tran-select Oct 2012=0A=0A=0A Advertise M= essage.=0A=0A 3. CPE MUST send Request message with OPTION=5FTRAN=5FTYPE= option code=0A in Option Request Option [RFC3115,section 22.7] to Server= .=0A=0A 4. Server replies Confirm message with OPTION=5FTRAN=5FTYPE opti= on to=0A CPE, which may allow or allocate a transition strategy (such as = mode=0A =3D 1).=0A=0A A server MAY include a TRAN=5FTYPE option in any = DHCPv6 message to=0A control the transition strategy selection of the CPE= , including=0A Solicit, Advertise, Request, Confirm, Renew, Rebind, Infor= mation-=0A Request Messages.=0A=0A The server can also send the OPTION= =5FTRA=5FTYPE option in Advertise=0A Message or Confirm Message directly = without the request OPTION in=0A Solicit or Request Message from CPE.=0A= =0A To avoid OPTION=5FTRAN=5FTYPE meanings ambiguity, the 'mode' field mu= st=0A be consisitent in any CPE and server in the same way in DHCP.=0A=0A= =0A5. Other questions=0A=0A 1. If there is a DHCP/DHCPv6 Relay between = the CPE and server, it=0A must forward the messages including this option= transparently.=0A=0A 2. Why choose DHCP and DHCPv6 to take this importa= nt option, not=0A just one of them? Because some of the transition techn= ologies only=0A use IPv4 or IPv6 in the CPEs' WAN interface. Obviously, = if CPE=0A choose 6RD as its default transition technology, it can only su= pport=0A DHCP. Contrarily, DS-Lite CPE only support IPv6 in its WAN in t= he=0A default configuration.=0A=0A 3. Although DHCP/DHCPv6 must be use= d in IPoE scenario, it may not be=0A launched in PPPoE network, which is = a popular protocol in the fixed=0A access networks. Then we must use oth= er solutions to solve this=0A problem.=0A=0A=0A6. Security Consideration= s=0A=0A The security problem is under disscussion.=0A=0A=0A7. IANA Consi= derations=0A=0A 1. IANA is requested to assign an option code from the "= DHCP Option=0A=0A=0A=0AYang, et al. Expires April 15, 2013 = [Page 6]=0A=0C=0AInternet-Draft IPv6tran-select = Oct 2012=0A=0A=0A Codes" and "DHCPv6 Option Codes" Regi= stry for OPTION=5FTRAN=5FTYPE.=0A=0A 2. IANA is also requested to assign= a uniform serial number for the=0A 'mode' field.=0A=0A=0A8. Refrences= =0A=0A (1) RFC[2131] Dynamic Host Configuration Protocol=0A=0A (2) RFC[= 2132] DHCP Options and BOOTP Vendor Extensions=0A=0A (3) RFC[3315] Dynami= c Host Configuration Protocol for IPv6(DHCPv6)=0A=0A=0AAuthors' Addresses= =0A=0A Tianle Yang=0A China Mobile=0A 32, Xuanwumenxi Ave.=0A Xiche= ng District, Beijing 100053=0A China=0A=0A Email: yangtianle@chinamobi= le.com=0A=0A=0A Li Lianyuan=0A China Mobile=0A 32, Xuanwumenxi Ave.= =0A Xicheng District, Beijing 100053=0A China=0A=0A Email: lilianyua= n@chinamobile.com=0A=0A=0A Qiongfang Ma=0A China Mobile=0A 32, Xuanw= umenxi Ave.=0A Xicheng District, Beijing 100053=0A China=0A=0A Email= : maqiongfang@chinamobile.com=0A=0A=0A=0A=0A=0A=0A=0A=0A=0AYang, et al. = Expires April 15, 2013 [Page 7]=0A=0C=0A= ------=_NextPart_000_008A_01CDB08A.EF660B30-- From leaf.y.yeh@huawei.com Mon Oct 22 04:31:42 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EFAB21F8BAF for ; Mon, 22 Oct 2012 04:31:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.502 X-Spam-Level: X-Spam-Status: No, score=-6.502 tagged_above=-999 required=5 tests=[AWL=0.097, 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 2xcD5Fq3T22m for ; Mon, 22 Oct 2012 04:31:42 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C599E21F8BB0 for ; Mon, 22 Oct 2012 04:31:40 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKV28842; Mon, 22 Oct 2012 11:31:33 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 22 Oct 2012 12:31:02 +0100 Received: from SZXEML447-HUB.china.huawei.com (10.82.67.185) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 22 Oct 2012 19:31:06 +0800 Received: from SZXEML546-MBX.china.huawei.com ([169.254.3.157]) by szxeml447-hub.china.huawei.com ([10.82.67.185]) with mapi id 14.01.0323.003; Mon, 22 Oct 2012 19:30:58 +0800 From: Leaf yeh To: "dhcwg@ietf.org" Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-prefix-pool-opt-01.txt Thread-Index: AQHNsEH01cT61a1CF0GnWTsMqj+suZfFI+Ew Date: Mon, 22 Oct 2012 11:30:59 +0000 Message-ID: References: <20121022104136.7949.92089.idtracker@ietfa.amsl.com> In-Reply-To: <20121022104136.7949.92089.idtracker@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.83.152] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: =?iso-8859-1?Q?Ole_Tr=F8an?= , "Bernie Volz \(volz\)" , Tomek Mrugalski Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-prefix-pool-opt-01.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, 22 Oct 2012 11:31:42 -0000 Dear folks, The draft (OPTION_PREFIX_POOL) has been updated to ver.-01. The updates can= be found at http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-dhcpv6-prefi= x-pool-opt-01. The meaningful revision from ver.-00 is: a. The update in the last paragraph of Section 6 addressed a technical issu= e on the DHCPv6 Bulk Leasquery raised by Tomek in the ML Your further comments are more than welcome. :-) Best Regards, Leaf -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of i= nternet-drafts@ietf.org Sent: Monday, October 22, 2012 6:42 PM To: i-d-announce@ietf.org Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-prefix-pool-opt-01.txt 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 Group = of the IETF. Title : Prefix Pool Option for DHCPv6 Relay Agents on Provider E= dge Routers Author(s) : Leaf Y. Yeh Ted Lemon Mohamed Boucadair Filename : draft-ietf-dhc-dhcpv6-prefix-pool-opt-01.txt Pages : 13 Date : 2012-10-22 Abstract: The DHCPv6 Prefix Pool option provides a mechanism for DHCPv6 Prefix Delegation (DHCPv6-PD), allowing the DHCPv6 server to notify a DHCPv6 relay agent implemented on a Provider Edge (PE) router about active prefix pools allocated by the DHCPv6 server to the PE router. The information of active prefix pools can be used to enforce IPv6 route aggregation on the PE router through adding or removing aggregation routes according to the status of the prefix pools. The advertising of the aggregation routes in the routing protocol enabled on the network-facing interface of PE routers will dramatically decreases the number of the routing table entries in the ISP network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-prefix-pool-opt There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-prefix-pool-opt-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-dhcpv6-prefix-pool-opt-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From internet-drafts@ietf.org Mon Oct 22 05:27:55 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68CCD21F8B9E; Mon, 22 Oct 2012 05:27:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 KaWU-2cplZyJ; Mon, 22 Oct 2012 05:27:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 011EF21F8B86; Mon, 22 Oct 2012 05:27:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121022122755.30822.39120.idtracker@ietfa.amsl.com> Date: Mon, 22 Oct 2012 05:27:55 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-addr-registration-01.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, 22 Oct 2012 12:27:55 -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 Group = of the IETF. Title : A Generic IPv6 Addresses Registration Solution Using DHC= Pv6 Author(s) : Sheng Jiang Gang Chen Suresh Krishnan Filename : draft-ietf-dhc-addr-registration-01.txt Pages : 11 Date : 2012-10-22 Abstract: In networks that are centrally managed, self-generated addresses cause traceability issues due to their decentralized nature. To minimize the issues due to lack of traceability, these self-generated addresses can be registered with the network for allowing centralized address administration. This document defines a generic address registration solution using DHCPv6, using a new ND option and a new DHCPv6 option in order to communicate the use of self-generated addresses. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-addr-registration There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-addr-registration-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From leaf.y.yeh@huawei.com Mon Oct 22 05:30:30 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2931A21F8A57 for ; Mon, 22 Oct 2012 05:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.506 X-Spam-Level: X-Spam-Status: No, score=-6.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 LMt8ntBQhSyo for ; Mon, 22 Oct 2012 05:30:29 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id BC9F721F897C for ; Mon, 22 Oct 2012 05:30:28 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKV33765; Mon, 22 Oct 2012 12:30:22 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 22 Oct 2012 13:30:17 +0100 Received: from SZXEML414-HUB.china.huawei.com (10.82.67.153) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 22 Oct 2012 13:30:21 +0100 Received: from SZXEML546-MBX.china.huawei.com ([169.254.3.157]) by SZXEML414-HUB.china.huawei.com ([10.82.67.153]) with mapi id 14.01.0323.003; Mon, 22 Oct 2012 20:30:10 +0800 From: Leaf yeh To: "Gaurav Halwasia (ghalwasi)" , "dhcwg@ietf.org" Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-03.txt Thread-Index: AQHNr/1HNSd5KF2CtUyzfSel6RTWmJfEmrcQ///FXoCAANF84A== Date: Mon, 22 Oct 2012 12:30:10 +0000 Message-ID: References: <20121022023022.31796.83986.idtracker@ietfa.amsl.com> <90903C21C73202418A48BFBE80AEE5EB1BD89EEA@xmb-aln-x06.cisco.com> In-Reply-To: <90903C21C73202418A48BFBE80AEE5EB1BD89EEA@xmb-aln-x06.cisco.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.83.152] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "Bernie Volz \(volz\)" , Tomek Mrugalski Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-03.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 12:30:30 -0000 Hi Gaurav, Thanks for your valuable comments. The following are my instant reply: Gaurav -* Abstract says, " This mechanism is meant to the centralized DHCPv= 6 server to select the right configuration for the requesting client ... ".= Does not it say " This mechanism is meant for the centralized DHCPv6 serve= r .." .? Editorial. Accepted, the text of "is meant for" sounds fine with me.=20 Gaurav - * Section 4 heading could say "DHCPv6 OPTION_RADIUS option" Editorial. How about "DHCPv6 RADIUS option"?=20 Gaurav - * Section 4 says, " only the attributes listed in the table below = may be included in the OPTION_RADIUS ". What about any other attributes whi= ch might be required in future.? Are you suggesting that a new specificatio= n will be required to include any other attribute in DHCPv6 RADIUS_OPTION o= ption.? IMO, keeping the attribute list open for the implementer will incr= ease the usability of this mechanism. I think this specification can just m= ention the attributes as one of the use-case.=20 Editorial. I adopted the roughly same text in my draft as that in the secti= on 4 of RFC4014. To avoid dependencies between the address allocation and other stat= e information between the RADIUS server and the DHCP server, the DHCP relay agent SHOULD include only the attributes in the table below in an instance of the RADIUS Attributes suboption. I need consult with the chair to work out a solution for your concern. Gaurav -* Section 5, "Relay Agent Behavior" says " The relay agent MUST sil= ently discard OPTION_RADIUS if received. ". Can you explain about it little more and what is your pr= oposal keeping "Relay Chaining" in mind.? Technical. Good point. How about ''The relay agent MUST silently discard OP= TION_RADIUS if received in the RELAY-REPL (13) message."=20 Best Regards, Leaf -----Original Message----- From: Gaurav Halwasia (ghalwasi) [mailto:ghalwasi@cisco.com]=20 Sent: Monday, October 22, 2012 3:02 PM To: Leaf yeh; dhcwg@ietf.org Cc: Bernie Volz (volz); Tomek Mrugalski Subject: RE: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-03.txt Hi Leaf, This is a useful work and I do support this work. I have few comments thoug= h. * Abstract says, " This mechanism is meant to the centralized DHCPv6 server= to select the right configuration for the requesting client ... ". Does no= t it say " This mechanism is meant for the centralized DHCPv6 server .." .? * Section 4 heading could say "DHCPv6 OPTION_RADIUS option" * Section 4 says, " only the attributes listed in the table below may be in= cluded in the OPTION_RADIUS ". What about any other attributes which might = be required in future.? Are you suggesting that a new specification will be= required to include any other attribute in DHCPv6 RADIUS_OPTION option.? I= MO, keeping the attribute list open for the implementer will increase the = usability of this mechanism. I think this specification can just mention th= e attributes as one of the use-case.=20 * Section 5, "Relay Agent Behavior" says " The relay agent MUST silently di= scard OPTION_RADIUS if received. ". Can you explain about it little more and what is your pr= oposal keeping "Relay Chaining" in mind.? Thanks, Gaurav -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of L= eaf yeh Sent: Monday, October 22, 2012 8:11 AM To: dhcwg@ietf.org Cc: Bernie Volz (volz); Tomek Mrugalski Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-03.txt Dear folks, Supposed it is ready for your thorough review again. Your further comments = are more than welcome. :-) BTW, there is no meaningful change from ver.-02 to ver.-03, just some expre= ssion in text. But there has some changes from ver.-01 to ver.-02. Best Regards, Leaf -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of i= nternet-drafts@ietf.org Sent: Monday, October 22, 2012 10:30 AM To: i-d-announce@ietf.org Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-03.txt 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 Group = of the IETF. Title : RADIUS Option for DHCPv6 Relay Agents on Broadband Acces= s Server Author(s) : Leaf Y. Yeh Mohamed Boucadair Ted Lemon Filename : draft-ietf-dhc-dhcpv6-radius-opt-03.txt Pages : 9 Date : 2012-10-21 Abstract: The DHCPv6 RADIUS option provides a mechanism to exchange authorization and identification information between relay agent and server. This mechanism is meant to the centralized DHCPv6 server to select the right configuration for the requesting client based on the authorization information received from the RADIUS server, which is not co-located with the DHCPv6 server. The NAS acts as DHCPv6 relay agent and RADIUS client simultaneously in this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-radius-opt There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-radius-opt-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-dhcpv6-radius-opt-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ 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 ghalwasi@cisco.com Mon Oct 22 05:48:02 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 083A421F889F for ; Mon, 22 Oct 2012 05:48:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.419 X-Spam-Level: X-Spam-Status: No, score=-10.419 tagged_above=-999 required=5 tests=[AWL=0.180, 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 jrcjOSUooJQY for ; Mon, 22 Oct 2012 05:48:01 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 2C6DF21F85E2 for ; Mon, 22 Oct 2012 05:48:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1851; q=dns/txt; s=iport; t=1350910081; x=1352119681; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=xjCdghppeGlILbP9w+y6n4tyjgDzKcf9M7RpoTusgTs=; b=WxOVnehflYUrETro4JjtloA8xDCfhdXiscQVCsxiGygzxnxePY/3llJ+ s38LDBwN6Xk7NNhW0nRLUL0F9KDpFdwEW8V+0O0K7IPKfsCs2Nd0ZIuac Yt3CwFYQmJvR9ARmpgQMcGTM6Ixn7dbjwKa+ULX4HmhMfJSDgAvvxbNGP w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAP0+hVCtJV2Y/2dsb2JhbABFwQyBCIIhAQEEEgEnPxACAQgiFBAyJQIEAQ0NEweHYpt4n0SRbmADpD+Ba4Jvghg X-IronPort-AV: E=Sophos;i="4.80,629,1344211200"; d="scan'208";a="134092319" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP; 22 Oct 2012 12:48:00 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9MCm04k017088 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Oct 2012 12:48:00 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.220]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.001; Mon, 22 Oct 2012 07:48:00 -0500 From: "Gaurav Halwasia (ghalwasi)" To: Leaf yeh , "dhcwg@ietf.org" Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-03.txt Thread-Index: AQHNr/1GDp5inQDbOkmGgNRDgWCa/pfE8SIA///wfyCAALQpAP//rRMg Date: Mon, 22 Oct 2012 12:47:59 +0000 Message-ID: <90903C21C73202418A48BFBE80AEE5EB1BD8BA7C@xmb-aln-x06.cisco.com> References: <20121022023022.31796.83986.idtracker@ietfa.amsl.com> <90903C21C73202418A48BFBE80AEE5EB1BD89EEA@xmb-aln-x06.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.69.59] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19294.004 x-tm-as-result: No--29.578700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Bernie Volz \(volz\)" , Tomek Mrugalski Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-03.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 12:48:02 -0000 Gaurav - * Section 4 heading could say "DHCPv6 OPTION_RADIUS option" Editorial. How about "DHCPv6 RADIUS option"?=20 [Gaurav] Yes, this looks good as well. Just "OPTION_RADIUS" was looking odd= . Gaurav - * Section 4 says, " only the attributes listed in the table below = may be included in the OPTION_RADIUS ". What about any other attributes whi= ch might be required in future.? Are you suggesting that a new specificatio= n will be required to include any other attribute in DHCPv6 RADIUS_OPTION o= ption.? IMO, keeping the attribute list open for the implementer will incr= ease the usability of this mechanism. I think this specification can just m= ention the attributes as one of the use-case.=20 Editorial. I adopted the roughly same text in my draft as that in the secti= on 4 of RFC4014. To avoid dependencies between the address allocation and other stat= e information between the RADIUS server and the DHCP server, the DHCP relay agent SHOULD include only the attributes in the table below in an instance of the RADIUS Attributes suboption. I need consult with the chair to work out a solution for your concern. [Gaurav] I understand you have borrowed this text from RFC4014. But I still= think that keeping the attribute space unrestricted will be good. Anyhow,= let me know when you arrive at any conclusion regarding this based upon yo= ur discussion with chair. Gaurav -* Section 5, "Relay Agent Behavior" says " The relay agent MUST sil= ently discard OPTION_RADIUS if received. ". Can you explain about it little more and what is your pr= oposal keeping "Relay Chaining" in mind.? Technical. Good point. How about ''The relay agent MUST silently discard OP= TION_RADIUS if received in the RELAY-REPL (13) message."=20 [Gaurav] I am fine with this text.=20 From mohamed.boucadair@orange.com Mon Oct 22 05:51:25 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 784D021F88AF for ; Mon, 22 Oct 2012 05:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.137 X-Spam-Level: X-Spam-Status: No, score=-2.137 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=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 rXXiIpsxeaxi for ; Mon, 22 Oct 2012 05:51:25 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id B29D721F8842 for ; Mon, 22 Oct 2012 05:51:24 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 3ADEE18C438 for ; Mon, 22 Oct 2012 14:51:23 +0200 (CEST) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 19D1027C057 for ; Mon, 22 Oct 2012 14:51:23 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Mon, 22 Oct 2012 14:51:22 +0200 From: To: "" Date: Mon, 22 Oct 2012 14:51:21 +0200 Thread-Topic: draft-boucadair-dhc-address-name-encoding Thread-Index: Ac2t86rjPooUbIPURI+UZrh4Eypd9wCYBoyg Message-ID: <94C682931C08B048B7A8645303FDC9F36E6556C2C8@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.19.115414 Subject: [dhcwg] draft-boucadair-dhc-address-name-encoding 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, 22 Oct 2012 12:51:25 -0000 Dear all, We submitted an updated version taking into account the comments we receive= d so far.=20 Please feel free to review and comment.=20 Cheers, Med -----Message d'origine----- De : i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] D= e la part de internet-drafts@ietf.org Envoy=E9 : vendredi 19 octobre 2012 14:17 =C0 : i-d-announce@ietf.org Objet : I-D Action: draft-boucadair-dhc-address-name-encoding-01.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Recommendation for Encoding IP Address and FQDN in DHCP = Options Author(s) : Mohamed Boucadair Roberta Maglione Filename : draft-boucadair-dhc-address-name-encoding-01.txt Pages : 8 Date : 2012-10-19 Abstract: This document aims at providing a recommendation for the design of future DHCP options when both IP Address and FQDN encoding are needed to be supported. This design reconciles the flexibility requirement from service providers and the DHC WG recommendation to avoid defining multiple options conveying similar set of configuration data. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-boucadair-dhc-address-name-encoding There's also a htmlized version available at: http://tools.ietf.org/html/draft-boucadair-dhc-address-name-encoding-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-dhc-address-name-encodin= g-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From simon.perreault@viagenie.ca Mon Oct 22 06:03:57 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1201C21F8BC5 for ; Mon, 22 Oct 2012 06:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-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 eBwwaySS2+vk for ; Mon, 22 Oct 2012 06:03:56 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 36B7E21F8B76 for ; Mon, 22 Oct 2012 06:03:56 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:8c54:f483:a6fd:5c0]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 9E16E44A83 for ; Mon, 22 Oct 2012 09:03:55 -0400 (EDT) Message-ID: <5085443B.5040202@viagenie.ca> Date: Mon, 22 Oct 2012 09:03:55 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121016 Thunderbird/16.0.1 MIME-Version: 1.0 To: dhcwg@ietf.org References: <9D3C0AC1-D5B1-4C25-AC47-4D08E3252D54@nominum.com> <35B57831-F31C-40D9-A34A-9469261F3636@employees.org> <50814AB3.9070307@cisco.com> <2D7C2D36-D308-4480-8858-9F5EF23EDC06@nominum.com> <50817BA9.6020503@cisco.com> <50824F32.1090602@cisco.com> <4DDC6ED5-C2FC-43A8-93D0-E06751D 67FB9@employees.org> <1EAF4610-FCE9-4DC0-B932-8DA1A3B34325@nominum.com> <3D3DC439-7976-43A4-8976-2E5A34BDB0A5@nominum.com> <9E57F2F7-8FE0-4FBF-8F53-9C04EED8C224@employees.org>, <50F98AE9-A285-4309-995E-FB7D3C5EC803@nominum.com> <9A8AB174-974A-4C85-9149-313A54CD4761@cisco.com> In-Reply-To: <9A8AB174-974A-4C85-9149-313A54CD4761@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [dhcwg] Call for adoption: draft-sun-dhc-port-set-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: Mon, 22 Oct 2012 13:03:57 -0000 Le 2012-10-20 17:23, Eliot Lear (elear) a écrit : > The point is to use a high bandwidth medium that is expressly set for > such occasions, a f2f meeting. It's not as if one has to wait so long... I, for one, am keeping myself from replying to this thread precisely because it ought to be discussed in Atlanta. I suspect others are doing the same... Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From internet-drafts@ietf.org Mon Oct 22 07:45:28 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA6821F8BBC; Mon, 22 Oct 2012 07:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.061, 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 SsMfjKjp3CmV; Mon, 22 Oct 2012 07:45:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD1CB21F8B8B; Mon, 22 Oct 2012 07:45:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121022144527.18073.67957.idtracker@ietfa.amsl.com> Date: Mon, 22 Oct 2012 07:45:27 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-failover-design-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, 22 Oct 2012 14:45:28 -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 Group = of the IETF. Title : DHCPv6 Failover Design Author(s) : Tomasz Mrugalski Kim Kinnear Filename : draft-ietf-dhc-dhcpv6-failover-design-02.txt Pages : 58 Date : 2012-10-22 Abstract: DHCPv6 defined in [RFC3315] does not offer server redundancy. This document defines a design for DHCPv6 failover, a mechanism for running two servers on the same network with capability for either server to take over clients' leases in case of server failure or network partition. This is a DHCPv6 Failover design document, it is not protocol specification document. It is a second document in a planned series of three documents. DHCPv6 failover requirements are specified in [I-D.ietf-dhc-dhcpv6-failover-requirements]. A protocol specification document is planned to follow this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-failover-design There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-failover-design-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-dhcpv6-failover-design-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From volz@cisco.com Mon Oct 22 08:25:00 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C3B821F8C09 for ; Mon, 22 Oct 2012 08:25:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.328 X-Spam-Level: X-Spam-Status: No, score=-10.328 tagged_above=-999 required=5 tests=[AWL=0.271, 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 HOV8RlqbQstp for ; Mon, 22 Oct 2012 08:24:59 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 2F4C121F8B79 for ; Mon, 22 Oct 2012 08:24:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4047; q=dns/txt; s=iport; t=1350919499; x=1352129099; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=CQkrLhy7y2XdKtuneC598aIEtUzTRlR0vDTjkQZGP8I=; b=g5qCnzQdijx9K5ucV0KZlCN9VZH2CAL7Fc7FEgUD2YQBWLAlBxWgB9YB thkqPqIUURKp/Fug7ZqltybIwdpKokOmroABbaiWf5MzeD6Qejh64BT94 D7QiTiKGUg9kebP+f+dyje1eGJ97sHv/sXWdGh18WRnbsDTEz7BaeoaHs Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAAFkhVCtJV2Y/2dsb2JhbABFwRGBCIIgAQEBBBIBJz8MBAIBCBEEAQELFBAyHQgCBAENBQgTB4dinBafX4tfhg9gA6Q/gWuCb4IY X-IronPort-AV: E=Sophos;i="4.80,630,1344211200"; d="scan'208";a="134146369" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 22 Oct 2012 15:24:58 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9MFOwI5004584 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Oct 2012 15:24:58 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.200]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.001; Mon, 22 Oct 2012 10:24:58 -0500 From: "Bernie Volz (volz)" To: "Gaurav Halwasia (ghalwasi)" , Leaf yeh , "dhcwg@ietf.org" Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-03.txt Thread-Index: AQHNr/1HNSd5KF2CtUyzfSel6RTWmJfEmrcQgACfTICAAFvHAIAABPuA///T6AA= Date: Mon, 22 Oct 2012 15:24:57 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E0F544231@xmb-rcd-x04.cisco.com> References: <20121022023022.31796.83986.idtracker@ietfa.amsl.com> <90903C21C73202418A48BFBE80AEE5EB1BD89EEA@xmb-aln-x06.cisco.com> <90903C21C73202418A48BFBE80AEE5EB1BD8BA7C@xmb-aln-x06.cisco.com> In-Reply-To: <90903C21C73202418A48BFBE80AEE5EB1BD8BA7C@xmb-aln-x06.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.253.147] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19294.004 x-tm-as-result: No--39.673900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Tomek Mrugalski Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-03.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 15:25:00 -0000 Hi: In general this looks very good now. And, I (mostly) agree with the changes= proposed. I would suggest the following minor changes: - In section 4, please indicate that the "one or a list of RADIUS Attribute= s" are encoded in RADIUS "format" and that this uses a 8-bit type and lengt= h and that the length includes the length octet? - Looks like the text "As the same method in [RFC4014], ..." has been repla= ced with the text mentioned below? Good if that is the case as I am not sur= e what "same method" really meant. Please also drop "Note: The above table = might have more attributes to join in the future." if that wasn't already d= one. I believe that future RADIUS Attribute documents can update this document i= f the attribute(s) are to be allowed in this option in the future. Perhaps = IANA could maintain a registry of the RADIUS attributes allowed in the opti= on; but I don't think we requested this for v4 and not sure it is really ne= eded for v6. - Regarding ... how about ''The relay agent MUST silently discard OPTION_RA= DIUS if received in the RELAY-REPL (13) message." Do you really want to specify this? The server is not supposed to echo back= options. BUT we do have the Echo Request Option (ERO, 43) which a relay co= uld use to request this information back if it needed it for some reason. S= o, I don't see a need to require this MUST and I think you should be silent= about it -- I would thus just remove the last sentence of the paragraph in= section 5. Though we also should fix the text in 6. Server Behavior. The last sentence= of: The DHCPv6 server MUST NOT include OPTION_RADIUS in RELAY-REPL (13) mess= ages. Should either be dropped or changed to read: The DHCPv6 server MUST NOT include the OPTION_RADIUS in RELAY-REPL (13) = messages unless requested by the relay agent in the Echo Request Option (OP= TION_ERO). - Bernie -----Original Message----- From: Gaurav Halwasia (ghalwasi)=20 Sent: Monday, October 22, 2012 8:48 AM To: Leaf yeh; dhcwg@ietf.org Cc: Bernie Volz (volz); Tomek Mrugalski Subject: RE: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-03.txt Gaurav - * Section 4 heading could say "DHCPv6 OPTION_RADIUS option" Editorial. How about "DHCPv6 RADIUS option"?=20 [Gaurav] Yes, this looks good as well. Just "OPTION_RADIUS" was looking odd= . Gaurav - * Section 4 says, " only the attributes listed in the table below = may be included in the OPTION_RADIUS ". What about any other attributes whi= ch might be required in future.? Are you suggesting that a new specificatio= n will be required to include any other attribute in DHCPv6 RADIUS_OPTION o= ption.? IMO, keeping the attribute list open for the implementer will incr= ease the usability of this mechanism. I think this specification can just m= ention the attributes as one of the use-case.=20 Editorial. I adopted the roughly same text in my draft as that in the secti= on 4 of RFC4014. To avoid dependencies between the address allocation and other stat= e information between the RADIUS server and the DHCP server, the DHCP relay agent SHOULD include only the attributes in the table below in an instance of the RADIUS Attributes suboption. I need consult with the chair to work out a solution for your concern. [Gaurav] I understand you have borrowed this text from RFC4014. But I still= think that keeping the attribute space unrestricted will be good. Anyhow,= let me know when you arrive at any conclusion regarding this based upon yo= ur discussion with chair. Gaurav -* Section 5, "Relay Agent Behavior" says " The relay agent MUST sil= ently discard OPTION_RADIUS if received. ". Can you explain about it little more and what is your pr= oposal keeping "Relay Chaining" in mind.? Technical. Good point. How about ''The relay agent MUST silently discard OP= TION_RADIUS if received in the RELAY-REPL (13) message."=20 [Gaurav] I am fine with this text.=20 From Ted.Lemon@nominum.com Mon Oct 22 08:44:47 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A26C121F84E4 for ; Mon, 22 Oct 2012 08:44:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.502 X-Spam-Level: X-Spam-Status: No, score=-106.502 tagged_above=-999 required=5 tests=[AWL=0.097, 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 v4TOBFP8-AvY for ; Mon, 22 Oct 2012 08:44:47 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id 1710821F8569 for ; Mon, 22 Oct 2012 08:44:47 -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 DSNKUIVp7j+Fzf3dAQ7g5hcQVTA/aA1QvJuO@postini.com; Mon, 22 Oct 2012 08:44: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 578B21B82B9 for ; Mon, 22 Oct 2012 08:44:46 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 4F0AA19005C for ; Mon, 22 Oct 2012 08:44:46 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Mon, 22 Oct 2012 08:44:46 -0700 From: Ted Lemon To: DHCP discussion list Thread-Topic: WGLC: draft-ietf-dhc-dhcpv6-failover-requirements-02 Thread-Index: AQHNsGwoW+LJmw3VLE2UWhN9JpdrFg== Date: Mon, 22 Oct 2012 15:44:45 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <1FD4E58495E28547B74E6A050D549FDE@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-failover-requirements-02 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, 22 Oct 2012 15:44:47 -0000 The authors have asked for a last call on the DHCPv6 failover requirements = draft. This just documents the list of requirements for a DHCPv6 failover= protocol. If you are interested in DHCPv6 failover, please review the do= cument and comment on the list. If you favor publishing this requirements= document, please say so. If you oppose publishing it, please also say so= . There will be a discussion about this document in the DHC working group mee= ting on November 8; depending on the outcome of that discussion and the res= ponse to this message, we will evaluate consensus on or about November 12. = From internet-drafts@ietf.org Mon Oct 22 08:48:40 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D9DF21F8C4C; Mon, 22 Oct 2012 08:48:40 -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 qkrKeUHZvHak; Mon, 22 Oct 2012 08:48:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADF5D21F8C47; Mon, 22 Oct 2012 08:48:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121022154839.6058.71568.idtracker@ietfa.amsl.com> Date: Mon, 22 Oct 2012 08:48:39 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-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, 22 Oct 2012 15:48:40 -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 Group = of the IETF. Title : Issues with multiple stateful DHCPv6 options Author(s) : Ole Troan Bernie Volz Filename : draft-ietf-dhc-dhcpv6-stateful-issues-02.txt Pages : 10 Date : 2012-10-22 Abstract: Dynamic Host Configuration Protocol for IPv6 (DHCPv6) was not written with the expectation that additional stateful DHCPv6 options would be developed. IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6 shoe-horned the new options for Prefix Delegation into DHCPv6. Implementation experience of the CPE model described in has shown multiple issues with the DHCPv6 protocol in supporting multiple stateful options. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-stateful-issues There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-stateful-issues-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-dhcpv6-stateful-issues-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From volz@cisco.com Mon Oct 22 08:58:06 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AAD621F8981 for ; Mon, 22 Oct 2012 08:58:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.345 X-Spam-Level: X-Spam-Status: No, score=-10.345 tagged_above=-999 required=5 tests=[AWL=0.254, 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 Xw7qYzuJwg2S for ; Mon, 22 Oct 2012 08:58:01 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 42F1021F8C0A for ; Mon, 22 Oct 2012 08:58:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2730; q=dns/txt; s=iport; t=1350921480; x=1352131080; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=lklG7TBIJEocFIpe01IpTCmwMhisM2KBlTiyS+5Jh48=; b=YlcCrrOS+UXiKsqWgEjLnIEKaxUKhkpigf2vVS1A0C7clmZZ8+qYO3p8 p+qf+insSV2MqiEXvrOyEpC1K+BMaMgyMCcv5wXFDaIQxx45FVA+eM5E6 /eeTaxZ8KW2jRl6p5rQSEYG+1Qv1FSDIK2Y3t4E5qigeKDHL/Jl4ojqUB s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALhshVCtJXHB/2dsb2JhbABFwRGBCIIgAQEBBAEBAQ8BJzQXBAIBCBEEAQELFAkHJwsUCQgCBBMIARmHYgucCp9ni1+GD2ADlwiNN4Frgm+CGA X-IronPort-AV: E=Sophos;i="4.80,630,1344211200"; d="scan'208";a="134127829" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-6.cisco.com with ESMTP; 22 Oct 2012 15:57:58 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q9MFvwtd016679 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 22 Oct 2012 15:57:58 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.200]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.001; Mon, 22 Oct 2012 10:57:57 -0500 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-02.txt Thread-Index: AQHNsGzT0FyP5oOW+E6ucf5QkY1WfJfFeQ0Q Date: Mon, 22 Oct 2012 15:57:57 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E0F544358@xmb-rcd-x04.cisco.com> References: <20121022154839.6058.71568.idtracker@ietfa.amsl.com> In-Reply-To: <20121022154839.6058.71568.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.253.147] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19294.004 x-tm-as-result: No--27.977900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-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, 22 Oct 2012 15:58:07 -0000 I just submitted the 02 version of this draft. The only change is the following paragraph was added to Section 4.2. Place= ment of Status codes: To clarify further: the expected Advertise message from a server when a client requests both address assignment (IA_NA) and prefix delegation (IA_PD) and the server can only delegate prefixes, is a Status Code Option with the NoAddrsAvail status code, no IA_NA option(s), and the IA_PD option(s) with IAPREFIX option(s). This was discussed recently (based on a message posted by David Miles on 10= /5 with subject "DHCPv6 NoAddrAvailable"). I didn't address that particular= case (where both address and prefix delegation failed), but described what= I thought was a more likely case. If there is a desire to expand the clari= fication to cover the NoAddrsAvail/NoPrefixAvail case, I could add text for= that too. - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of i= nternet-drafts@ietf.org Sent: Monday, October 22, 2012 11:49 AM To: i-d-announce@ietf.org Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-02.txt 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 Group = of the IETF. Title : Issues with multiple stateful DHCPv6 options Author(s) : Ole Troan Bernie Volz Filename : draft-ietf-dhc-dhcpv6-stateful-issues-02.txt Pages : 10 Date : 2012-10-22 Abstract: Dynamic Host Configuration Protocol for IPv6 (DHCPv6) was not written with the expectation that additional stateful DHCPv6 options would be developed. IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6 shoe-horned the new options for Prefix Delegation into DHCPv6. Implementation experience of the CPE model described in has shown multiple issues with the DHCPv6 protocol in supporting multiple stateful options. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-stateful-issues There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-stateful-issues-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-dhcpv6-stateful-issues-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From Ted.Lemon@nominum.com Mon Oct 22 09:36:16 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E59821F8B73 for ; Mon, 22 Oct 2012 09:36:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.503 X-Spam-Level: X-Spam-Status: No, score=-106.503 tagged_above=-999 required=5 tests=[AWL=0.096, 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 RCI4bV7DjaE4 for ; Mon, 22 Oct 2012 09:36:15 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id BC25621F8B66 for ; Mon, 22 Oct 2012 09:36:15 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKUIV1/y7Re+xqtCwkBmFGfVydLPG7K4da@postini.com; Mon, 22 Oct 2012 09:36:15 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 E4BDE1B82C5 for ; Mon, 22 Oct 2012 09:36:14 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id D9A1619005C; Mon, 22 Oct 2012 09:36:14 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Mon, 22 Oct 2012 09:36:14 -0700 From: Ted Lemon To: "Bernie Volz (volz)" Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-02.txt Thread-Index: AQHNsGzRKG67f1J1W0CWFbh/9n68J5fF8ICAgAAKsgA= Date: Mon, 22 Oct 2012 16:36:14 +0000 Message-ID: <353D80BF-2100-4570-8089-139ADBB596F5@nominum.com> References: <20121022154839.6058.71568.idtracker@ietfa.amsl.com> <489D13FBFA9B3E41812EA89F188F018E0F544358@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E0F544358@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-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, 22 Oct 2012 16:36:16 -0000 On Oct 22, 2012, at 11:57 AM, Bernie Volz (volz) wrote: > To clarify further: the expected Advertise message from a server when > a client requests both address assignment (IA_NA) and prefix > delegation (IA_PD) and the server can only delegate prefixes, is a > Status Code Option with the NoAddrsAvail status code, no IA_NA > option(s), and the IA_PD option(s) with IAPREFIX option(s). Difficult to parse. How about: To clarify further: when a client requests both IA_NA and IA_PD, and the se= rver can offer IA_PD but not IA_NA, the server should send a response conta= ining no IA_NA, a status code of NoAddrsAvail, and one or more IA_PD option= s containing IA_PREFIX options. From volz@cisco.com Mon Oct 22 19:22:12 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1265F1F0C54 for ; Mon, 22 Oct 2012 19:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.505 X-Spam-Level: X-Spam-Status: No, score=-10.505 tagged_above=-999 required=5 tests=[AWL=0.094, 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 2hG2wHqTlFZL for ; Mon, 22 Oct 2012 19:22:11 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id DEBC91F0429 for ; Mon, 22 Oct 2012 19:22:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1570; q=dns/txt; s=iport; t=1350958931; x=1352168531; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=CRkHr7GMylhIShkhm5m0cia3DGqpvRsDGRqR09ETw6Q=; b=l7jErvCNXrgyLbIq3nQdMF77RL39eJqBp/gp9hUKvQOw8DB/23FsDiGr A5RFuijJjDwfEiThmo5OI2tbxMw+cbQExg/EWJs/zsJo4WzEt1JL3ng9z SONB3WP13Wei+y9IKajKUAwcxu5Ls/+i6U7LIkYibX2X4JLxYya77pU1Y Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAGz+hVCtJV2b/2dsb2JhbABEwWCBCIIgAQEBBAEBAQ8BJzQLDAQCAQgRBAEBAQoUCQcnCxQJCAIEDgUIGodiC5wtj1yQUgSLWIYPYAOkP4FrgmINgVoHGR4 X-IronPort-AV: E=Sophos;i="4.80,633,1344211200"; d="scan'208";a="134293204" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-2.cisco.com with ESMTP; 23 Oct 2012 02:22:10 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q9N2MA1A015496 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 23 Oct 2012 02:22:10 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.200]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.001; Mon, 22 Oct 2012 21:22:10 -0500 From: "Bernie Volz (volz)" To: Ted Lemon Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-02.txt Thread-Index: AQHNsGzT0FyP5oOW+E6ucf5QkY1WfJfFeQ0QgABgngCAAE3CgA== Date: Tue, 23 Oct 2012 02:22:09 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E0F545298@xmb-rcd-x04.cisco.com> References: <20121022154839.6058.71568.idtracker@ietfa.amsl.com> <489D13FBFA9B3E41812EA89F188F018E0F544358@xmb-rcd-x04.cisco.com> <353D80BF-2100-4570-8089-139ADBB596F5@nominum.com> In-Reply-To: <353D80BF-2100-4570-8089-139ADBB596F5@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.253.123] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19294.004 x-tm-as-result: No--34.016200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-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, 23 Oct 2012 02:22:12 -0000 I will update, but will revise to make it clear this is for Solicit/Adverti= se. Reply semantics aren't the same. How about: To clarify further: when a client requests both IA_NA and IA_PD, and the se= rver can offer IA_PD but not IA_NA, the server sends an Advertise response = containing no IA_NA option, a status code option of NoAddrsAvail, and one o= r more IA_PD options containing IAPREFIX options. - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= ed Lemon Sent: Monday, October 22, 2012 12:36 PM To: Bernie Volz (volz) Cc: dhcwg@ietf.org Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-02.t= xt On Oct 22, 2012, at 11:57 AM, Bernie Volz (volz) wrote: > To clarify further: the expected Advertise message from a server when > a client requests both address assignment (IA_NA) and prefix > delegation (IA_PD) and the server can only delegate prefixes, is a > Status Code Option with the NoAddrsAvail status code, no IA_NA > option(s), and the IA_PD option(s) with IAPREFIX option(s). Difficult to parse. How about: To clarify further: when a client requests both IA_NA and IA_PD, and the se= rver can offer IA_PD but not IA_NA, the server should send a response conta= ining no IA_NA, a status code of NoAddrsAvail, and one or more IA_PD option= s containing IA_PREFIX options. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From Stephen.Jacob@nominum.com Tue Oct 23 00:20:01 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 420B521F8922 for ; Tue, 23 Oct 2012 00:20:01 -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 481c7pz81+AS for ; Tue, 23 Oct 2012 00:20:00 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id 56F6621F891F for ; Tue, 23 Oct 2012 00:20:00 -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 DSNKUIZFH9Pd6RdHvp7WfNtYYLXi7/RQN48T@postini.com; Tue, 23 Oct 2012 00:20:00 PDT Received: by shell-too.nominum.com (Postfix, from userid 11053) id A97761B82CF; Tue, 23 Oct 2012 00:19:58 -0700 (PDT) Date: Tue, 23 Oct 2012 00:19:58 -0700 From: Stephen Jacob To: "Bernie Volz (volz)" Message-ID: <20121023071958.GA22736@shell-too.nominum.com> Mail-Followup-To: "Bernie Volz (volz)" , Ted Lemon , "dhcwg@ietf.org" References: <20121022154839.6058.71568.idtracker@ietfa.amsl.com> <489D13FBFA9B3E41812EA89F188F018E0F544358@xmb-rcd-x04.cisco.com> <353D80BF-2100-4570-8089-139ADBB596F5@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F545298@xmb-rcd-x04.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E0F545298@xmb-rcd-x04.cisco.com> User-Agent: Mutt/1.4.2.2i X-URI: http://www.nominum.com/ Organization: Nominum, Inc. Cc: "dhcwg@ietf.org" , Ted Lemon Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-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, 23 Oct 2012 07:20:01 -0000 I like this wording. It definitely adds clarity. Regards, Stephen On Tue, Oct 23, 2012 at 02:22:09AM +0000, Bernie Volz (volz) wrote: > I will update, but will revise to make it clear this is for Solicit/Advertise. Reply semantics aren't the same. How about: > > To clarify further: when a client requests both IA_NA and IA_PD, and the server can offer IA_PD but not IA_NA, the server sends an Advertise response containing no IA_NA option, a status code option of NoAddrsAvail, and one or more IA_PD options containing IAPREFIX options. > > - Bernie > > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Ted Lemon > Sent: Monday, October 22, 2012 12:36 PM > To: Bernie Volz (volz) > Cc: dhcwg@ietf.org > Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-02.txt > > On Oct 22, 2012, at 11:57 AM, Bernie Volz (volz) wrote: > > To clarify further: the expected Advertise message from a server when > > a client requests both address assignment (IA_NA) and prefix > > delegation (IA_PD) and the server can only delegate prefixes, is a > > Status Code Option with the NoAddrsAvail status code, no IA_NA > > option(s), and the IA_PD option(s) with IAPREFIX option(s). > > Difficult to parse. How about: > > To clarify further: when a client requests both IA_NA and IA_PD, and the server can offer IA_PD but not IA_NA, the server should send a response containing no IA_NA, a status code of NoAddrsAvail, and one or more IA_PD options containing IA_PREFIX options. > > _______________________________________________ > 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 -- Stephen Jacob | Stephen.Jacob@nominum.com | +1 650 381 6051 Nominum, Inc. | http://www.nominum.com/ | +1 650 381 6000 From david@pheynix.net Tue Oct 23 00:21:33 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C56B021F8922 for ; Tue, 23 Oct 2012 00:21:32 -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 4-9SaaeaIV5L for ; Tue, 23 Oct 2012 00:21:31 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id C2E1121F8917 for ; Tue, 23 Oct 2012 00:21:31 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id fb11so2527319pad.31 for ; Tue, 23 Oct 2012 00:21:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pheynix.net; s=google; h=date:from:to:message-id:in-reply-to:references:subject:x-mailer :mime-version:content-type:content-transfer-encoding :content-disposition; bh=e3hRzDu7B77GP+F1OGy8zFXXiPJF3tlChG/T10CEuPY=; b=DO2mARdBNkfA4GSYoAo0u8aRAJJE6Q5ekJNhbWwsA4UqsnrOKoHke73CgVMO5AN9OH pPygYT9LLISyN4yqxz3KMFGuWjmEQ0eQVlyu1+J5M8xJQc9wYsW0M5qNA5b0ypnoMTRZ R8aXlNp2yVVg6oDBQ3EeeEp4Bl4kyJgDplglE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:message-id:in-reply-to:references:subject:x-mailer :mime-version:content-type:content-transfer-encoding :content-disposition:x-gm-message-state; bh=e3hRzDu7B77GP+F1OGy8zFXXiPJF3tlChG/T10CEuPY=; b=ciRBimrLDylErL+pEEmpj2tKYuGfHI7M4iYmsTGe7xhLDTuKOphmfowJKIjNEsY076 xeyIeq20bNBMpzkD40JZwKt3DXjMFK2P26K1f1LvpWxIQoNOWenlR8IZ8YQk2Kw4fCOV JhCIlbWDRWdcgCslqOangHZWDEemylqEvBMtg6xooBRi/X4COYHsniSxvA/gDWfOPIZ5 AFWgBRF1ag8g64sYViInAPUwWiSr/IqngolL1fWH3aCEQKlAGVxYXyQM07Nl/mOYhkjp NhU2/MfZbFeIUODZJsQjhO/+ka0lZzlP+AwoOldNHABy+uB2SnWThm/w+oRhnTseDGb+ RDGg== Received: by 10.68.213.1 with SMTP id no1mr37210539pbc.123.1350976891590; Tue, 23 Oct 2012 00:21:31 -0700 (PDT) Received: from [10.33.1.102] ([63.216.66.4]) by mx.google.com with ESMTPS id ju7sm7260286pbb.60.2012.10.23.00.21.30 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 23 Oct 2012 00:21:31 -0700 (PDT) Date: Tue, 23 Oct 2012 00:21:41 -0700 From: David Miles To: "Bernie Volz (volz)" , Ted Lemon , "=?utf-8?Q?dhcwg=40ietf.org?=" Message-ID: <83E431C045BF42A58A0DF2E25E6777F2@pheynix.net> In-Reply-To: <20121023071958.GA22736@shell-too.nominum.com> References: <20121022154839.6058.71568.idtracker@ietfa.amsl.com> <489D13FBFA9B3E41812EA89F188F018E0F544358@xmb-rcd-x04.cisco.com> <353D80BF-2100-4570-8089-139ADBB596F5@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F545298@xmb-rcd-x04.cisco.com> <20121023071958.GA22736@shell-too.nominum.com> X-Mailer: sparrow 1.6.4 (build 1176) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Gm-Message-State: ALoCoQk2158/BctLVE5cAfVgz9GAd1KtrMcRAb0ez8df4wKBeaSrZTDliT6N0RXkbGVo9vSVWUu4 Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-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, 23 Oct 2012 07:21:33 -0000 Agreed, thanks Bernie -- David Miles On Tuesday, October 23, 2012 at 12:19 AM, Stephen Jacob wrote: > I like this wording. It definitely adds clarity. > > Regards, > Stephen > > On Tue, Oct 23, 2012 at 02:22:09AM +0000, Bernie Volz (volz) wrote: > > I will update, but will revise to make it clear this is for Solicit/Advertise. Reply semantics aren't the same. How about: > > > > To clarify further: when a client requests both IA_NA and IA_PD, and the server can offer IA_PD but not IA_NA, the server sends an Advertise response containing no IA_NA option, a status code option of NoAddrsAvail, and one or more IA_PD options containing IAPREFIX options. > > > > - Bernie From leaf.y.yeh@huawei.com Tue Oct 23 02:58:25 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68A9221F8659 for ; Tue, 23 Oct 2012 02:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.51 X-Spam-Level: X-Spam-Status: No, score=-6.51 tagged_above=-999 required=5 tests=[AWL=0.089, 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 podr2z7kpyXC for ; Tue, 23 Oct 2012 02:58:24 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1C3CE21F863F for ; Tue, 23 Oct 2012 02:58:23 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALZ28732; Tue, 23 Oct 2012 09:58:23 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 23 Oct 2012 10:57:37 +0100 Received: from SZXEML426-HUB.china.huawei.com (10.72.61.34) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 23 Oct 2012 10:57:43 +0100 Received: from SZXEML546-MBX.china.huawei.com ([169.254.3.157]) by szxeml426-hub.china.huawei.com ([10.72.61.34]) with mapi id 14.01.0323.003; Tue, 23 Oct 2012 17:57:29 +0800 From: Leaf yeh To: "Bernie Volz (volz)" , "Gaurav Halwasia (ghalwasi)" , "dhcwg@ietf.org" Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-03.txt Thread-Index: AQHNr/1HNSd5KF2CtUyzfSel6RTWmJfEmrcQ///FXoCAANF84P//j0aAgAAr24CAAYQpQA== Date: Tue, 23 Oct 2012 09:57:27 +0000 Message-ID: References: <20121022023022.31796.83986.idtracker@ietfa.amsl.com> <90903C21C73202418A48BFBE80AEE5EB1BD89EEA@xmb-aln-x06.cisco.com> <90903C21C73202418A48BFBE80AEE5EB1BD8BA7C@xmb-aln-x06.cisco.com> <489D13FBFA9B3E41812EA89F188F018E0F544231@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E0F544231@xmb-rcd-x04.cisco.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.83.152] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Tomek Mrugalski Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-03.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 09:58:25 -0000 Hi Bernie, Thanks for your valuable comments. Bernie - In section 4, please indicate that the "one or a list of RADIUS At= tributes" are encoded in RADIUS "format" and that this uses a 8-bit type an= d length and that the length includes the length octet? Editorial. The format of the RADIUS attribute in the traditional type space= is defined in section 5 of RFC2865. The format of the RADIUS attribute in = the extended type space is defined in section 2 of draft-ietf-radext-radius= -extensions. The definition of their 'Length' field are identical for the l= ength of the whole attribute including the TLV fields of 'Type', 'Length', = 'Value' and/or 'Extended-Type', 'M-flag', 'Reserved'. I'd like OPTION_RADIU= S could also include the attributes defined in the future which employed th= e extended type space, but have no objection to your suggestion for the cla= rification on the 'length' field of RADIUS attribute.=20 How about add a note after the table as follows: 'Note: The one-octet 'Leng= th' field in the RADIUS attribute indicates the length of the whole attribu= te.' ? Bernie - Looks like the text "As the same method in [RFC4014], ..." has bee= n replaced with the text mentioned below? Good if that is the case as I am = not sure what "same method" really meant. Please also drop "Note: The above= table might have more attributes to join in the future." if that wasn't al= ready done. Editorial. I am fine to drop the text of ' As the same method in [RFC4014],= ' and 'Note: The above table might have more attributes to join in the futu= re.' Bernie - So, I don't see a need to require this MUST and I think you should= be silent about it -- I would thus just remove the last sentence of the pa= ragraph in section 5. Editorial. Accepted if ERO (43) sounds a concern. Bernie - Should either be dropped or changed to read: Editorial. I tend to drop the last sentence in section 6, because I have no= t seen the use case (or necessity) to introduce ERO (43) here. Best Regards, Leaf -----Original Message----- From: Bernie Volz (volz) [mailto:volz@cisco.com]=20 Sent: Monday, October 22, 2012 11:25 PM To: Gaurav Halwasia (ghalwasi); Leaf yeh; dhcwg@ietf.org Cc: Tomek Mrugalski Subject: RE: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-03.txt Hi: In general this looks very good now. And, I (mostly) agree with the changes= proposed. I would suggest the following minor changes: - In section 4, please indicate that the "one or a list of RADIUS Attribute= s" are encoded in RADIUS "format" and that this uses a 8-bit type and lengt= h and that the length includes the length octet? - Looks like the text "As the same method in [RFC4014], ..." has been repla= ced with the text mentioned below? Good if that is the case as I am not sur= e what "same method" really meant. Please also drop "Note: The above table = might have more attributes to join in the future." if that wasn't already d= one. I believe that future RADIUS Attribute documents can update this document i= f the attribute(s) are to be allowed in this option in the future. Perhaps = IANA could maintain a registry of the RADIUS attributes allowed in the opti= on; but I don't think we requested this for v4 and not sure it is really ne= eded for v6. - Regarding ... how about ''The relay agent MUST silently discard OPTION_RA= DIUS if received in the RELAY-REPL (13) message." Do you really want to specify this? The server is not supposed to echo back= options. BUT we do have the Echo Request Option (ERO, 43) which a relay co= uld use to request this information back if it needed it for some reason. S= o, I don't see a need to require this MUST and I think you should be silent= about it -- I would thus just remove the last sentence of the paragraph in= section 5. Though we also should fix the text in 6. Server Behavior. The last sentence= of: The DHCPv6 server MUST NOT include OPTION_RADIUS in RELAY-REPL (13) mess= ages. Should either be dropped or changed to read: The DHCPv6 server MUST NOT include the OPTION_RADIUS in RELAY-REPL (13) = messages unless requested by the relay agent in the Echo Request Option (OP= TION_ERO). - Bernie -----Original Message----- From: Gaurav Halwasia (ghalwasi)=20 Sent: Monday, October 22, 2012 8:48 AM To: Leaf yeh; dhcwg@ietf.org Cc: Bernie Volz (volz); Tomek Mrugalski Subject: RE: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-03.txt Gaurav - * Section 4 heading could say "DHCPv6 OPTION_RADIUS option" Editorial. How about "DHCPv6 RADIUS option"?=20 [Gaurav] Yes, this looks good as well. Just "OPTION_RADIUS" was looking odd= . Gaurav - * Section 4 says, " only the attributes listed in the table below = may be included in the OPTION_RADIUS ". What about any other attributes whi= ch might be required in future.? Are you suggesting that a new specificatio= n will be required to include any other attribute in DHCPv6 RADIUS_OPTION o= ption.? IMO, keeping the attribute list open for the implementer will incr= ease the usability of this mechanism. I think this specification can just m= ention the attributes as one of the use-case.=20 Editorial. I adopted the roughly same text in my draft as that in the secti= on 4 of RFC4014. To avoid dependencies between the address allocation and other stat= e information between the RADIUS server and the DHCP server, the DHCP relay agent SHOULD include only the attributes in the table below in an instance of the RADIUS Attributes suboption. I need consult with the chair to work out a solution for your concern. [Gaurav] I understand you have borrowed this text from RFC4014. But I still= think that keeping the attribute space unrestricted will be good. Anyhow,= let me know when you arrive at any conclusion regarding this based upon yo= ur discussion with chair. Gaurav -* Section 5, "Relay Agent Behavior" says " The relay agent MUST sil= ently discard OPTION_RADIUS if received. ". Can you explain about it little more and what is your pr= oposal keeping "Relay Chaining" in mind.? Technical. Good point. How about ''The relay agent MUST silently discard OP= TION_RADIUS if received in the RELAY-REPL (13) message."=20 [Gaurav] I am fine with this text.=20 From volz@cisco.com Tue Oct 23 04:28:09 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5E6321F86CF for ; Tue, 23 Oct 2012 04:28:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.511 X-Spam-Level: X-Spam-Status: No, score=-10.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 a9WqofP4-jOn for ; Tue, 23 Oct 2012 04:28:08 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 0F53C21F86E0 for ; Tue, 23 Oct 2012 04:28:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6848; q=dns/txt; s=iport; t=1350991682; x=1352201282; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=/lfFPFAKa0YDbbjqPuh3vjf/ixFyCmQ/ymViZocc98Y=; b=TbQTcevTmDUqZoiLPDglRMGZaLyNZQmjEeVnO/6K3TU8V8vD2bz8JYBl N7n1GEXrkggjDWngQOKgJr5UVS4lUNeOrTA6KP13WSua5O8EJq5YBzSaC OTexgJEba/31TJnJtAXMxdLU04GZPfvF4m9zS8BfbmTJv5osfJdCPXegP 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAGd+hlCtJXG+/2dsb2JhbABEwWOBCIIeAQEBAwESASc/BQcEAgEIEQQBAR8JBzIUCQgCBA4FGweHXAacYo9ckEKLX4V+YAOVcY5OgWuCbw X-IronPort-AV: E=Sophos;i="4.80,634,1344211200"; d="scan'208";a="131422744" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-9.cisco.com with ESMTP; 23 Oct 2012 11:28:01 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9NBS1Ap025344 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 23 Oct 2012 11:28:01 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.200]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.001; Tue, 23 Oct 2012 06:28:00 -0500 From: "Bernie Volz (volz)" To: Leaf yeh Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-03.txt Thread-Index: AQHNr/1HNSd5KF2CtUyzfSel6RTWmJfEmrcQgACfTICAAFvHAIAABPuA///T6ACAAY7HgP//xXte Date: Tue, 23 Oct 2012 11:28:00 +0000 Message-ID: References: <20121022023022.31796.83986.idtracker@ietfa.amsl.com> <90903C21C73202418A48BFBE80AEE5EB1BD89EEA@xmb-aln-x06.cisco.com> <90903C21C73202418A48BFBE80AEE5EB1BD8BA7C@xmb-aln-x06.cisco.com> <489D13FBFA9B3E41812EA89F188F018E0F544231@xmb-rcd-x04.cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19298.000 x-tm-as-result: No--66.672700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , Tomek Mrugalski Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-03.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 11:28:09 -0000 For issue about Radius attributes, why not just include those cross referen= ces? Sent from my iPad On Oct 23, 2012, at 5:58 AM, "Leaf yeh" wrote: > Hi Bernie, >=20 > Thanks for your valuable comments. >=20 > Bernie - In section 4, please indicate that the "one or a list of RADIUS = Attributes" are encoded in RADIUS "format" and that this uses a 8-bit type = and length and that the length includes the length octet? >=20 > Editorial. The format of the RADIUS attribute in the traditional type spa= ce is defined in section 5 of RFC2865. The format of the RADIUS attribute i= n the extended type space is defined in section 2 of draft-ietf-radext-radi= us-extensions. The definition of their 'Length' field are identical for the= length of the whole attribute including the TLV fields of 'Type', 'Length'= , 'Value' and/or 'Extended-Type', 'M-flag', 'Reserved'. I'd like OPTION_RAD= IUS could also include the attributes defined in the future which employed = the extended type space, but have no objection to your suggestion for the c= larification on the 'length' field of RADIUS attribute.=20 >=20 > How about add a note after the table as follows: 'Note: The one-octet 'Le= ngth' field in the RADIUS attribute indicates the length of the whole attri= bute.' ? >=20 >=20 > Bernie - Looks like the text "As the same method in [RFC4014], ..." has b= een replaced with the text mentioned below? Good if that is the case as I a= m not sure what "same method" really meant. Please also drop "Note: The abo= ve table might have more attributes to join in the future." if that wasn't = already done. >=20 > Editorial. I am fine to drop the text of ' As the same method in [RFC4014= ],' and 'Note: The above table might have more attributes to join in the fu= ture.' >=20 >=20 > Bernie - So, I don't see a need to require this MUST and I think you shou= ld be silent about it -- I would thus just remove the last sentence of the = paragraph in section 5. >=20 > Editorial. Accepted if ERO (43) sounds a concern. >=20 >=20 > Bernie - Should either be dropped or changed to read: >=20 > Editorial. I tend to drop the last sentence in section 6, because I have = not seen the use case (or necessity) to introduce ERO (43) here. >=20 >=20 > Best Regards, > Leaf >=20 >=20 >=20 > -----Original Message----- > From: Bernie Volz (volz) [mailto:volz@cisco.com]=20 > Sent: Monday, October 22, 2012 11:25 PM > To: Gaurav Halwasia (ghalwasi); Leaf yeh; dhcwg@ietf.org > Cc: Tomek Mrugalski > Subject: RE: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-03.txt >=20 > Hi: >=20 > In general this looks very good now. And, I (mostly) agree with the chang= es proposed. >=20 > I would suggest the following minor changes: >=20 > - In section 4, please indicate that the "one or a list of RADIUS Attribu= tes" are encoded in RADIUS "format" and that this uses a 8-bit type and len= gth and that the length includes the length octet? >=20 > - Looks like the text "As the same method in [RFC4014], ..." has been rep= laced with the text mentioned below? Good if that is the case as I am not s= ure what "same method" really meant. Please also drop "Note: The above tabl= e might have more attributes to join in the future." if that wasn't already= done. >=20 > I believe that future RADIUS Attribute documents can update this document= if the attribute(s) are to be allowed in this option in the future. Perhap= s IANA could maintain a registry of the RADIUS attributes allowed in the op= tion; but I don't think we requested this for v4 and not sure it is really = needed for v6. >=20 > - Regarding ... how about ''The relay agent MUST silently discard OPTION_= RADIUS if received in the RELAY-REPL (13) message." >=20 > Do you really want to specify this? The server is not supposed to echo ba= ck options. BUT we do have the Echo Request Option (ERO, 43) which a relay = could use to request this information back if it needed it for some reason.= So, I don't see a need to require this MUST and I think you should be sile= nt about it -- I would thus just remove the last sentence of the paragraph = in section 5. >=20 > Though we also should fix the text in 6. Server Behavior. The last senten= ce of: >=20 > The DHCPv6 server MUST NOT include OPTION_RADIUS in RELAY-REPL (13) mes= sages. >=20 > Should either be dropped or changed to read: >=20 > The DHCPv6 server MUST NOT include the OPTION_RADIUS in RELAY-REPL (13)= messages unless requested by the relay agent in the Echo Request Option (O= PTION_ERO). >=20 > - Bernie >=20 >=20 > -----Original Message----- > From: Gaurav Halwasia (ghalwasi)=20 > Sent: Monday, October 22, 2012 8:48 AM > To: Leaf yeh; dhcwg@ietf.org > Cc: Bernie Volz (volz); Tomek Mrugalski > Subject: RE: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-03.txt >=20 > Gaurav - * Section 4 heading could say "DHCPv6 OPTION_RADIUS option" > Editorial. How about "DHCPv6 RADIUS option"?=20 > [Gaurav] Yes, this looks good as well. Just "OPTION_RADIUS" was looking o= dd. >=20 > Gaurav - * Section 4 says, " only the attributes listed in the table belo= w may be included in the OPTION_RADIUS ". What about any other attributes w= hich might be required in future.? Are you suggesting that a new specificat= ion will be required to include any other attribute in DHCPv6 RADIUS_OPTION= option.? IMO, keeping the attribute list open for the implementer will in= crease the usability of this mechanism. I think this specification can just= mention the attributes as one of the use-case.=20 >=20 > Editorial. I adopted the roughly same text in my draft as that in the sec= tion 4 of RFC4014. >=20 > To avoid dependencies between the address allocation and other sta= te > information between the RADIUS server and the DHCP server, the DHCP > relay agent SHOULD include only the attributes in the table below in > an instance of the RADIUS Attributes suboption. >=20 > I need consult with the chair to work out a solution for your concern. > [Gaurav] I understand you have borrowed this text from RFC4014. But I sti= ll think that keeping the attribute space unrestricted will be good. Anyho= w, let me know when you arrive at any conclusion regarding this based upon = your discussion with chair. >=20 > Gaurav -* Section 5, "Relay Agent Behavior" says " The relay agent MUST s= ilently discard OPTION_RADIUS > if received. ". Can you explain about it little more and what is your p= roposal keeping "Relay Chaining" in mind.? >=20 > Technical. Good point. How about ''The relay agent MUST silently discard = OPTION_RADIUS if received in the RELAY-REPL (13) message."=20 > [Gaurav] I am fine with this text.=20 >=20 From leaf.y.yeh@huawei.com Tue Oct 23 04:33:34 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB72021F86E9 for ; Tue, 23 Oct 2012 04:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.514 X-Spam-Level: X-Spam-Status: No, score=-6.514 tagged_above=-999 required=5 tests=[AWL=0.085, 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 z-+6lBGSky14 for ; Tue, 23 Oct 2012 04:33:34 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6D1AB21F86E0 for ; Tue, 23 Oct 2012 04:33:33 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALZ37156; Tue, 23 Oct 2012 11:33:32 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 23 Oct 2012 12:33:24 +0100 Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 23 Oct 2012 12:33:31 +0100 Received: from SZXEML546-MBX.china.huawei.com ([169.254.3.157]) by szxeml403-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Tue, 23 Oct 2012 19:33:26 +0800 From: Leaf yeh To: "Bernie Volz (volz)" Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-03.txt Thread-Index: AQHNr/1HNSd5KF2CtUyzfSel6RTWmJfEmrcQ///FXoCAANF84P//j0aAgAAr24CAAYQpQP//y/gAABDMguA= Date: Tue, 23 Oct 2012 11:33:24 +0000 Message-ID: References: <20121022023022.31796.83986.idtracker@ietfa.amsl.com> <90903C21C73202418A48BFBE80AEE5EB1BD89EEA@xmb-aln-x06.cisco.com> <90903C21C73202418A48BFBE80AEE5EB1BD8BA7C@xmb-aln-x06.cisco.com> <489D13FBFA9B3E41812EA89F188F018E0F544231@xmb-rcd-x04.cisco.com>, In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.83.152] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "dhcwg@ietf.org" , Tomek Mrugalski Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-03.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 11:33:34 -0000 Bernie - For issue about Radius attributes... What do you mean for the 'issue'?=20 Best Regards, Leaf -----Original Message----- From: Bernie Volz (volz) [mailto:volz@cisco.com]=20 Sent: Tuesday, October 23, 2012 7:28 PM To: Leaf yeh Cc: Gaurav Halwasia (ghalwasi); dhcwg@ietf.org; Tomek Mrugalski Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-03.txt For issue about Radius attributes, why not just include those cross referen= ces? Sent from my iPad On Oct 23, 2012, at 5:58 AM, "Leaf yeh" wrote: > Hi Bernie, >=20 > Thanks for your valuable comments. >=20 > Bernie - In section 4, please indicate that the "one or a list of RADIUS = Attributes" are encoded in RADIUS "format" and that this uses a 8-bit type = and length and that the length includes the length octet? >=20 > Editorial. The format of the RADIUS attribute in the traditional type spa= ce is defined in section 5 of RFC2865. The format of the RADIUS attribute i= n the extended type space is defined in section 2 of draft-ietf-radext-radi= us-extensions. The definition of their 'Length' field are identical for the= length of the whole attribute including the TLV fields of 'Type', 'Length'= , 'Value' and/or 'Extended-Type', 'M-flag', 'Reserved'. I'd like OPTION_RAD= IUS could also include the attributes defined in the future which employed = the extended type space, but have no objection to your suggestion for the c= larification on the 'length' field of RADIUS attribute.=20 >=20 > How about add a note after the table as follows: 'Note: The one-octet 'Le= ngth' field in the RADIUS attribute indicates the length of the whole attri= bute.' ? >=20 >=20 > Bernie - Looks like the text "As the same method in [RFC4014], ..." has b= een replaced with the text mentioned below? Good if that is the case as I a= m not sure what "same method" really meant. Please also drop "Note: The abo= ve table might have more attributes to join in the future." if that wasn't = already done. >=20 > Editorial. I am fine to drop the text of ' As the same method in [RFC4014= ],' and 'Note: The above table might have more attributes to join in the fu= ture.' >=20 >=20 > Bernie - So, I don't see a need to require this MUST and I think you shou= ld be silent about it -- I would thus just remove the last sentence of the = paragraph in section 5. >=20 > Editorial. Accepted if ERO (43) sounds a concern. >=20 >=20 > Bernie - Should either be dropped or changed to read: >=20 > Editorial. I tend to drop the last sentence in section 6, because I have = not seen the use case (or necessity) to introduce ERO (43) here. >=20 >=20 > Best Regards, > Leaf >=20 >=20 >=20 > -----Original Message----- > From: Bernie Volz (volz) [mailto:volz@cisco.com]=20 > Sent: Monday, October 22, 2012 11:25 PM > To: Gaurav Halwasia (ghalwasi); Leaf yeh; dhcwg@ietf.org > Cc: Tomek Mrugalski > Subject: RE: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-03.txt >=20 > Hi: >=20 > In general this looks very good now. And, I (mostly) agree with the chang= es proposed. >=20 > I would suggest the following minor changes: >=20 > - In section 4, please indicate that the "one or a list of RADIUS Attribu= tes" are encoded in RADIUS "format" and that this uses a 8-bit type and len= gth and that the length includes the length octet? >=20 > - Looks like the text "As the same method in [RFC4014], ..." has been rep= laced with the text mentioned below? Good if that is the case as I am not s= ure what "same method" really meant. Please also drop "Note: The above tabl= e might have more attributes to join in the future." if that wasn't already= done. >=20 > I believe that future RADIUS Attribute documents can update this document= if the attribute(s) are to be allowed in this option in the future. Perhap= s IANA could maintain a registry of the RADIUS attributes allowed in the op= tion; but I don't think we requested this for v4 and not sure it is really = needed for v6. >=20 > - Regarding ... how about ''The relay agent MUST silently discard OPTION_= RADIUS if received in the RELAY-REPL (13) message." >=20 > Do you really want to specify this? The server is not supposed to echo ba= ck options. BUT we do have the Echo Request Option (ERO, 43) which a relay = could use to request this information back if it needed it for some reason.= So, I don't see a need to require this MUST and I think you should be sile= nt about it -- I would thus just remove the last sentence of the paragraph = in section 5. >=20 > Though we also should fix the text in 6. Server Behavior. The last senten= ce of: >=20 > The DHCPv6 server MUST NOT include OPTION_RADIUS in RELAY-REPL (13) mes= sages. >=20 > Should either be dropped or changed to read: >=20 > The DHCPv6 server MUST NOT include the OPTION_RADIUS in RELAY-REPL (13)= messages unless requested by the relay agent in the Echo Request Option (O= PTION_ERO). >=20 > - Bernie >=20 >=20 > -----Original Message----- > From: Gaurav Halwasia (ghalwasi)=20 > Sent: Monday, October 22, 2012 8:48 AM > To: Leaf yeh; dhcwg@ietf.org > Cc: Bernie Volz (volz); Tomek Mrugalski > Subject: RE: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-03.txt >=20 > Gaurav - * Section 4 heading could say "DHCPv6 OPTION_RADIUS option" > Editorial. How about "DHCPv6 RADIUS option"?=20 > [Gaurav] Yes, this looks good as well. Just "OPTION_RADIUS" was looking o= dd. >=20 > Gaurav - * Section 4 says, " only the attributes listed in the table belo= w may be included in the OPTION_RADIUS ". What about any other attributes w= hich might be required in future.? Are you suggesting that a new specificat= ion will be required to include any other attribute in DHCPv6 RADIUS_OPTION= option.? IMO, keeping the attribute list open for the implementer will in= crease the usability of this mechanism. I think this specification can just= mention the attributes as one of the use-case.=20 >=20 > Editorial. I adopted the roughly same text in my draft as that in the sec= tion 4 of RFC4014. >=20 > To avoid dependencies between the address allocation and other sta= te > information between the RADIUS server and the DHCP server, the DHCP > relay agent SHOULD include only the attributes in the table below in > an instance of the RADIUS Attributes suboption. >=20 > I need consult with the chair to work out a solution for your concern. > [Gaurav] I understand you have borrowed this text from RFC4014. But I sti= ll think that keeping the attribute space unrestricted will be good. Anyho= w, let me know when you arrive at any conclusion regarding this based upon = your discussion with chair. >=20 > Gaurav -* Section 5, "Relay Agent Behavior" says " The relay agent MUST s= ilently discard OPTION_RADIUS > if received. ". Can you explain about it little more and what is your p= roposal keeping "Relay Chaining" in mind.? >=20 > Technical. Good point. How about ''The relay agent MUST silently discard = OPTION_RADIUS if received in the RELAY-REPL (13) message."=20 > [Gaurav] I am fine with this text.=20 >=20 From volz@cisco.com Tue Oct 23 04:34:48 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B121821F86E9 for ; Tue, 23 Oct 2012 04:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.36 X-Spam-Level: X-Spam-Status: No, score=-10.36 tagged_above=-999 required=5 tests=[AWL=0.239, 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 DxpJgMhexvzn for ; Tue, 23 Oct 2012 04:34:47 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id ADE4D21F86DF for ; Tue, 23 Oct 2012 04:34:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8530; q=dns/txt; s=iport; t=1350992087; x=1352201687; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=R8+QEXay3lPhFcPvoBYtLXsqhbnI2HY2fyRWutW5Qrg=; b=K7QHCnhcCMby0NDyqZUWO69wfEYP0bAjtTQVOWpbCrizIHZfkY8mBUlK ZsxKD/kVnOidPCSAYwhvTSNK9Kl4xjtl7Z4U1cCkzldnASSMosIg4/TYk NV7abc84fsAIm+H8rfB+vDDkou+dJi9t8m8PMomBtNGj+vzK3zFg7oF9g U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAImAhlCtJXG9/2dsb2JhbABEwWOBCIIeAQEBAwEBAQEPASc0CwUHBAIBCBEEAQEBHgkHJwsUCQgCBA4FGweHXAYLnFSPXJBABItfhX5gA5Vxjk6Ba4Jv X-IronPort-AV: E=Sophos;i="4.80,634,1344211200"; d="scan'208";a="134406147" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-2.cisco.com with ESMTP; 23 Oct 2012 11:34:29 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9NBYS8f023193 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 23 Oct 2012 11:34:28 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.200]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.001; Tue, 23 Oct 2012 06:34:28 -0500 From: "Bernie Volz (volz)" To: Leaf yeh Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-03.txt Thread-Index: AQHNr/1HNSd5KF2CtUyzfSel6RTWmJfEmrcQgACfTICAAFvHAIAABPuA///T6ACAAY7HgP//xXtegABVVAD//6x7HQ== Date: Tue, 23 Oct 2012 11:34:28 +0000 Message-ID: References: <20121022023022.31796.83986.idtracker@ietfa.amsl.com> <90903C21C73202418A48BFBE80AEE5EB1BD89EEA@xmb-aln-x06.cisco.com> <90903C21C73202418A48BFBE80AEE5EB1BD8BA7C@xmb-aln-x06.cisco.com> <489D13FBFA9B3E41812EA89F188F018E0F544231@xmb-rcd-x04.cisco.com>, , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19298.000 x-tm-as-result: No--72.001000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , Tomek Mrugalski Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-03.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 11:34:48 -0000 >> Bernie - In section 4, please indicate that the "one or a list of RADIUS= Attributes" are encoded in RADIUS "format" and that this uses a 8-bit type= and length and that the length includes the length octet? >>=20 >> Editorial. The format of the RADIUS attribute in the traditional type sp= ace is defined in section 5 of RFC2865. The format of the RADIUS attribute = in the extended type space is defined in section 2 of draft-ietf-radext-rad= ius-extensions. The definition of their 'Length' field are identical for th= e length of the whole attribute including the TLV fields of 'Type', 'Length= ', 'Value' and/or 'Extended-Type', 'M-flag', 'Reserved'. I'd like OPTION_RA= DIUS could also include the attributes defined in the future which employed= the extended type space, but have no objection to your suggestion for the = clarification on the 'length' field of RADIUS attribute.=20 >=20 Sent from my iPad On Oct 23, 2012, at 7:33 AM, "Leaf yeh" wrote: > Bernie - For issue about Radius attributes... >=20 > What do you mean for the 'issue'?=20 >=20 >=20 > Best Regards, > Leaf >=20 >=20 > -----Original Message----- > From: Bernie Volz (volz) [mailto:volz@cisco.com]=20 > Sent: Tuesday, October 23, 2012 7:28 PM > To: Leaf yeh > Cc: Gaurav Halwasia (ghalwasi); dhcwg@ietf.org; Tomek Mrugalski > Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-03.txt >=20 > For issue about Radius attributes, why not just include those cross refer= ences? >=20 > Sent from my iPad >=20 > On Oct 23, 2012, at 5:58 AM, "Leaf yeh" wrote: >=20 >> Hi Bernie, >>=20 >> Thanks for your valuable comments. >>=20 >> Bernie - In section 4, please indicate that the "one or a list of RADIUS= Attributes" are encoded in RADIUS "format" and that this uses a 8-bit type= and length and that the length includes the length octet? >>=20 >> Editorial. The format of the RADIUS attribute in the traditional type sp= ace is defined in section 5 of RFC2865. The format of the RADIUS attribute = in the extended type space is defined in section 2 of draft-ietf-radext-rad= ius-extensions. The definition of their 'Length' field are identical for th= e length of the whole attribute including the TLV fields of 'Type', 'Length= ', 'Value' and/or 'Extended-Type', 'M-flag', 'Reserved'. I'd like OPTION_RA= DIUS could also include the attributes defined in the future which employed= the extended type space, but have no objection to your suggestion for the = clarification on the 'length' field of RADIUS attribute.=20 >>=20 >> How about add a note after the table as follows: 'Note: The one-octet 'L= ength' field in the RADIUS attribute indicates the length of the whole attr= ibute.' ? >>=20 >>=20 >> Bernie - Looks like the text "As the same method in [RFC4014], ..." has = been replaced with the text mentioned below? Good if that is the case as I = am not sure what "same method" really meant. Please also drop "Note: The ab= ove table might have more attributes to join in the future." if that wasn't= already done. >>=20 >> Editorial. I am fine to drop the text of ' As the same method in [RFC401= 4],' and 'Note: The above table might have more attributes to join in the f= uture.' >>=20 >>=20 >> Bernie - So, I don't see a need to require this MUST and I think you sho= uld be silent about it -- I would thus just remove the last sentence of the= paragraph in section 5. >>=20 >> Editorial. Accepted if ERO (43) sounds a concern. >>=20 >>=20 >> Bernie - Should either be dropped or changed to read: >>=20 >> Editorial. I tend to drop the last sentence in section 6, because I have= not seen the use case (or necessity) to introduce ERO (43) here. >>=20 >>=20 >> Best Regards, >> Leaf >>=20 >>=20 >>=20 >> -----Original Message----- >> From: Bernie Volz (volz) [mailto:volz@cisco.com]=20 >> Sent: Monday, October 22, 2012 11:25 PM >> To: Gaurav Halwasia (ghalwasi); Leaf yeh; dhcwg@ietf.org >> Cc: Tomek Mrugalski >> Subject: RE: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-03.txt >>=20 >> Hi: >>=20 >> In general this looks very good now. And, I (mostly) agree with the chan= ges proposed. >>=20 >> I would suggest the following minor changes: >>=20 >> - In section 4, please indicate that the "one or a list of RADIUS Attrib= utes" are encoded in RADIUS "format" and that this uses a 8-bit type and le= ngth and that the length includes the length octet? >>=20 >> - Looks like the text "As the same method in [RFC4014], ..." has been re= placed with the text mentioned below? Good if that is the case as I am not = sure what "same method" really meant. Please also drop "Note: The above tab= le might have more attributes to join in the future." if that wasn't alread= y done. >>=20 >> I believe that future RADIUS Attribute documents can update this documen= t if the attribute(s) are to be allowed in this option in the future. Perha= ps IANA could maintain a registry of the RADIUS attributes allowed in the o= ption; but I don't think we requested this for v4 and not sure it is really= needed for v6. >>=20 >> - Regarding ... how about ''The relay agent MUST silently discard OPTION= _RADIUS if received in the RELAY-REPL (13) message." >>=20 >> Do you really want to specify this? The server is not supposed to echo b= ack options. BUT we do have the Echo Request Option (ERO, 43) which a relay= could use to request this information back if it needed it for some reason= . So, I don't see a need to require this MUST and I think you should be sil= ent about it -- I would thus just remove the last sentence of the paragraph= in section 5. >>=20 >> Though we also should fix the text in 6. Server Behavior. The last sente= nce of: >>=20 >> The DHCPv6 server MUST NOT include OPTION_RADIUS in RELAY-REPL (13) mes= sages. >>=20 >> Should either be dropped or changed to read: >>=20 >> The DHCPv6 server MUST NOT include the OPTION_RADIUS in RELAY-REPL (13)= messages unless requested by the relay agent in the Echo Request Option (O= PTION_ERO). >>=20 >> - Bernie >>=20 >>=20 >> -----Original Message----- >> From: Gaurav Halwasia (ghalwasi)=20 >> Sent: Monday, October 22, 2012 8:48 AM >> To: Leaf yeh; dhcwg@ietf.org >> Cc: Bernie Volz (volz); Tomek Mrugalski >> Subject: RE: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-03.txt >>=20 >> Gaurav - * Section 4 heading could say "DHCPv6 OPTION_RADIUS option" >> Editorial. How about "DHCPv6 RADIUS option"?=20 >> [Gaurav] Yes, this looks good as well. Just "OPTION_RADIUS" was looking = odd. >>=20 >> Gaurav - * Section 4 says, " only the attributes listed in the table bel= ow may be included in the OPTION_RADIUS ". What about any other attributes = which might be required in future.? Are you suggesting that a new specifica= tion will be required to include any other attribute in DHCPv6 RADIUS_OPTIO= N option.? IMO, keeping the attribute list open for the implementer will i= ncrease the usability of this mechanism. I think this specification can jus= t mention the attributes as one of the use-case.=20 >>=20 >> Editorial. I adopted the roughly same text in my draft as that in the se= ction 4 of RFC4014. >>=20 >> To avoid dependencies between the address allocation and other st= ate >> information between the RADIUS server and the DHCP server, the DHCP >> relay agent SHOULD include only the attributes in the table below in >> an instance of the RADIUS Attributes suboption. >>=20 >> I need consult with the chair to work out a solution for your concern. >> [Gaurav] I understand you have borrowed this text from RFC4014. But I st= ill think that keeping the attribute space unrestricted will be good. Anyh= ow, let me know when you arrive at any conclusion regarding this based upon= your discussion with chair. >>=20 >> Gaurav -* Section 5, "Relay Agent Behavior" says " The relay agent MUST = silently discard OPTION_RADIUS >> if received. ". Can you explain about it little more and what is your p= roposal keeping "Relay Chaining" in mind.? >>=20 >> Technical. Good point. How about ''The relay agent MUST silently discard= OPTION_RADIUS if received in the RELAY-REPL (13) message."=20 >> [Gaurav] I am fine with this text. > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From leaf.y.yeh@huawei.com Tue Oct 23 04:45:32 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD59F21F86E6 for ; Tue, 23 Oct 2012 04:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.518 X-Spam-Level: X-Spam-Status: No, score=-6.518 tagged_above=-999 required=5 tests=[AWL=0.081, 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 6NpGM+gqAqXp for ; Tue, 23 Oct 2012 04:45:29 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A7ED721F86AB for ; Tue, 23 Oct 2012 04:45:28 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKW21072; Tue, 23 Oct 2012 11:45:25 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 23 Oct 2012 12:44:54 +0100 Received: from SZXEML448-HUB.china.huawei.com (10.82.67.191) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 23 Oct 2012 12:45:01 +0100 Received: from SZXEML546-MBX.china.huawei.com ([169.254.3.157]) by szxeml448-hub.china.huawei.com ([10.82.67.191]) with mapi id 14.01.0323.003; Tue, 23 Oct 2012 19:44:22 +0800 From: Leaf yeh To: "Bernie Volz (volz)" Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-03.txt Thread-Index: AQHNr/1HNSd5KF2CtUyzfSel6RTWmJfEmrcQ///FXoCAANF84P//j0aAgAAr24CAAYQpQP//y/gAABDMguD//3tqAP//eVJA Date: Tue, 23 Oct 2012 11:44:21 +0000 Message-ID: References: <20121022023022.31796.83986.idtracker@ietfa.amsl.com> <90903C21C73202418A48BFBE80AEE5EB1BD89EEA@xmb-aln-x06.cisco.com> <90903C21C73202418A48BFBE80AEE5EB1BD8BA7C@xmb-aln-x06.cisco.com> <489D13FBFA9B3E41812EA89F188F018E0F544231@xmb-rcd-x04.cisco.com>, , In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.83.152] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "dhcwg@ietf.org" , Tomek Mrugalski Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-03.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 11:45:33 -0000 How about add a note after the table in section 4 as follows: 'Note: The on= e-octet 'Length' field in the RADIUS attribute defined in section 5 of RFC2= 865, indicates the length of the whole attribute' ? draft-ietf-radext-radius-extensions @ http://datatracker.ietf.org/d= oc/draft-ietf-radext-radius-extensions/?include_text=3D1 - section 2.1 + 2.= 2 : Length This field is identical to the Length field of the Attribute format defined in [RFC2865] Section 5. Best Regards, Leaf -----Original Message----- From: Bernie Volz (volz) [mailto:volz@cisco.com]=20 Sent: Tuesday, October 23, 2012 7:34 PM To: Leaf yeh Cc: dhcwg@ietf.org; Tomek Mrugalski Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-03.txt >> Bernie - In section 4, please indicate that the "one or a list of RADIUS= Attributes" are encoded in RADIUS "format" and that this uses a 8-bit type= and length and that the length includes the length octet? >>=20 >> Editorial. The format of the RADIUS attribute in the traditional type sp= ace is defined in section 5 of RFC2865. The format of the RADIUS attribute = in the extended type space is defined in section 2 of draft-ietf-radext-rad= ius-extensions. The definition of their 'Length' field are identical for th= e length of the whole attribute including the TLV fields of 'Type', 'Length= ', 'Value' and/or 'Extended-Type', 'M-flag', 'Reserved'. I'd like OPTION_RA= DIUS could also include the attributes defined in the future which employed= the extended type space, but have no objection to your suggestion for the = clarification on the 'length' field of RADIUS attribute.=20 >=20 Sent from my iPad On Oct 23, 2012, at 7:33 AM, "Leaf yeh" wrote: > Bernie - For issue about Radius attributes... >=20 > What do you mean for the 'issue'?=20 >=20 >=20 > Best Regards, > Leaf >=20 >=20 > -----Original Message----- > From: Bernie Volz (volz) [mailto:volz@cisco.com]=20 > Sent: Tuesday, October 23, 2012 7:28 PM > To: Leaf yeh > Cc: Gaurav Halwasia (ghalwasi); dhcwg@ietf.org; Tomek Mrugalski > Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-03.txt >=20 > For issue about Radius attributes, why not just include those cross refer= ences? >=20 > Sent from my iPad >=20 > On Oct 23, 2012, at 5:58 AM, "Leaf yeh" wrote: >=20 >> Hi Bernie, >>=20 >> Thanks for your valuable comments. >>=20 >> Bernie - In section 4, please indicate that the "one or a list of RADIUS= Attributes" are encoded in RADIUS "format" and that this uses a 8-bit type= and length and that the length includes the length octet? >>=20 >> Editorial. The format of the RADIUS attribute in the traditional type sp= ace is defined in section 5 of RFC2865. The format of the RADIUS attribute = in the extended type space is defined in section 2 of draft-ietf-radext-rad= ius-extensions. The definition of their 'Length' field are identical for th= e length of the whole attribute including the TLV fields of 'Type', 'Length= ', 'Value' and/or 'Extended-Type', 'M-flag', 'Reserved'. I'd like OPTION_RA= DIUS could also include the attributes defined in the future which employed= the extended type space, but have no objection to your suggestion for the = clarification on the 'length' field of RADIUS attribute.=20 >>=20 >> How about add a note after the table as follows: 'Note: The one-octet 'L= ength' field in the RADIUS attribute indicates the length of the whole attr= ibute.' ? >>=20 >>=20 >> Bernie - Looks like the text "As the same method in [RFC4014], ..." has = been replaced with the text mentioned below? Good if that is the case as I = am not sure what "same method" really meant. Please also drop "Note: The ab= ove table might have more attributes to join in the future." if that wasn't= already done. >>=20 >> Editorial. I am fine to drop the text of ' As the same method in [RFC401= 4],' and 'Note: The above table might have more attributes to join in the f= uture.' >>=20 >>=20 >> Bernie - So, I don't see a need to require this MUST and I think you sho= uld be silent about it -- I would thus just remove the last sentence of the= paragraph in section 5. >>=20 >> Editorial. Accepted if ERO (43) sounds a concern. >>=20 >>=20 >> Bernie - Should either be dropped or changed to read: >>=20 >> Editorial. I tend to drop the last sentence in section 6, because I have= not seen the use case (or necessity) to introduce ERO (43) here. >>=20 >>=20 >> Best Regards, >> Leaf >>=20 >>=20 >>=20 >> -----Original Message----- >> From: Bernie Volz (volz) [mailto:volz@cisco.com]=20 >> Sent: Monday, October 22, 2012 11:25 PM >> To: Gaurav Halwasia (ghalwasi); Leaf yeh; dhcwg@ietf.org >> Cc: Tomek Mrugalski >> Subject: RE: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-03.txt >>=20 >> Hi: >>=20 >> In general this looks very good now. And, I (mostly) agree with the chan= ges proposed. >>=20 >> I would suggest the following minor changes: >>=20 >> - In section 4, please indicate that the "one or a list of RADIUS Attrib= utes" are encoded in RADIUS "format" and that this uses a 8-bit type and le= ngth and that the length includes the length octet? >>=20 >> - Looks like the text "As the same method in [RFC4014], ..." has been re= placed with the text mentioned below? Good if that is the case as I am not = sure what "same method" really meant. Please also drop "Note: The above tab= le might have more attributes to join in the future." if that wasn't alread= y done. >>=20 >> I believe that future RADIUS Attribute documents can update this documen= t if the attribute(s) are to be allowed in this option in the future. Perha= ps IANA could maintain a registry of the RADIUS attributes allowed in the o= ption; but I don't think we requested this for v4 and not sure it is really= needed for v6. >>=20 >> - Regarding ... how about ''The relay agent MUST silently discard OPTION= _RADIUS if received in the RELAY-REPL (13) message." >>=20 >> Do you really want to specify this? The server is not supposed to echo b= ack options. BUT we do have the Echo Request Option (ERO, 43) which a relay= could use to request this information back if it needed it for some reason= . So, I don't see a need to require this MUST and I think you should be sil= ent about it -- I would thus just remove the last sentence of the paragraph= in section 5. >>=20 >> Though we also should fix the text in 6. Server Behavior. The last sente= nce of: >>=20 >> The DHCPv6 server MUST NOT include OPTION_RADIUS in RELAY-REPL (13) mes= sages. >>=20 >> Should either be dropped or changed to read: >>=20 >> The DHCPv6 server MUST NOT include the OPTION_RADIUS in RELAY-REPL (13)= messages unless requested by the relay agent in the Echo Request Option (O= PTION_ERO). >>=20 >> - Bernie >>=20 >>=20 >> -----Original Message----- >> From: Gaurav Halwasia (ghalwasi)=20 >> Sent: Monday, October 22, 2012 8:48 AM >> To: Leaf yeh; dhcwg@ietf.org >> Cc: Bernie Volz (volz); Tomek Mrugalski >> Subject: RE: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-03.txt >>=20 >> Gaurav - * Section 4 heading could say "DHCPv6 OPTION_RADIUS option" >> Editorial. How about "DHCPv6 RADIUS option"?=20 >> [Gaurav] Yes, this looks good as well. Just "OPTION_RADIUS" was looking = odd. >>=20 >> Gaurav - * Section 4 says, " only the attributes listed in the table bel= ow may be included in the OPTION_RADIUS ". What about any other attributes = which might be required in future.? Are you suggesting that a new specifica= tion will be required to include any other attribute in DHCPv6 RADIUS_OPTIO= N option.? IMO, keeping the attribute list open for the implementer will i= ncrease the usability of this mechanism. I think this specification can jus= t mention the attributes as one of the use-case.=20 >>=20 >> Editorial. I adopted the roughly same text in my draft as that in the se= ction 4 of RFC4014. >>=20 >> To avoid dependencies between the address allocation and other st= ate >> information between the RADIUS server and the DHCP server, the DHCP >> relay agent SHOULD include only the attributes in the table below in >> an instance of the RADIUS Attributes suboption. >>=20 >> I need consult with the chair to work out a solution for your concern. >> [Gaurav] I understand you have borrowed this text from RFC4014. But I st= ill think that keeping the attribute space unrestricted will be good. Anyh= ow, let me know when you arrive at any conclusion regarding this based upon= your discussion with chair. >>=20 >> Gaurav -* Section 5, "Relay Agent Behavior" says " The relay agent MUST = silently discard OPTION_RADIUS >> if received. ". Can you explain about it little more and what is your p= roposal keeping "Relay Chaining" in mind.? >>=20 >> Technical. Good point. How about ''The relay agent MUST silently discard= OPTION_RADIUS if received in the RELAY-REPL (13) message."=20 >> [Gaurav] I am fine with this text. > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From volz@cisco.com Tue Oct 23 06:12:43 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F35321F86FD for ; Tue, 23 Oct 2012 06:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.516 X-Spam-Level: X-Spam-Status: No, score=-10.516 tagged_above=-999 required=5 tests=[AWL=0.083, 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 hklgbVqlukv8 for ; Tue, 23 Oct 2012 06:12:42 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 3707721F86F3 for ; Tue, 23 Oct 2012 06:12:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9886; q=dns/txt; s=iport; t=1350997962; x=1352207562; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=DaXMzV4GDYtEd0eWW8UI7D+Ph/B3V4uo+4KWzkyx7qg=; b=Hq55Vin+1EHIvu9wBbqmBlKcpXx/INJYkkqU08EMJUKWlliDb5zHDH86 zkab1PhMwizaszSKzDyp++CAVYibwU3zoKTUwoaFkS4+Z0i+Y6N33Gami drYN8f/pTwKCFMNiU2hO/vfeibI9tCRGQI+8ua9+dh93bm6jS35cwgpJc Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAGmXhlCtJV2b/2dsb2JhbABEwWWBCIIeAQEBAwEBAQEPASc0CwUHBAIBCBEEAQEBHgkHJwsUCQgCBA4FGweHXAYLnCaPXJA6i1+FfmADlXGBF403gWuCbw X-IronPort-AV: E=Sophos;i="4.80,635,1344211200"; d="scan'208";a="134452013" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 23 Oct 2012 13:12:41 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q9NDCfOc002424 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 23 Oct 2012 13:12:41 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.200]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.001; Tue, 23 Oct 2012 08:12:40 -0500 From: "Bernie Volz (volz)" To: Leaf yeh Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-03.txt Thread-Index: AQHNr/1HNSd5KF2CtUyzfSel6RTWmJfEmrcQgACfTICAAFvHAIAABPuA///T6ACAAY7HgP//xXtegABVVAD//6x7HQAK0pWA///E2+s= Date: Tue, 23 Oct 2012 13:12:40 +0000 Message-ID: References: <20121022023022.31796.83986.idtracker@ietfa.amsl.com> <90903C21C73202418A48BFBE80AEE5EB1BD89EEA@xmb-aln-x06.cisco.com> <90903C21C73202418A48BFBE80AEE5EB1BD8BA7C@xmb-aln-x06.cisco.com> <489D13FBFA9B3E41812EA89F188F018E0F544231@xmb-rcd-x04.cisco.com>, , , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19298.000 x-tm-as-result: No--72.848700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , Tomek Mrugalski Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-03.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 13:12:43 -0000 I don't like "whole attribute" ... What does that mean? It may be best to j= ust ref the Radius documents. Perhaps a note that "While RADIUS uses TLV en= coding for attributes as DHCP does for options, the L (length) for RADIUS a= ttributes is defined differently than for DHCP options." Sent from my iPad On Oct 23, 2012, at 7:45 AM, "Leaf yeh" wrote: > How about add a note after the table in section 4 as follows: 'Note: The = one-octet 'Length' field in the RADIUS attribute defined in section 5 of RF= C2865, indicates the length of the whole attribute' ? >=20 >=20 > draft-ietf-radext-radius-extensions @ http://datatracker.ietf.org= /doc/draft-ietf-radext-radius-extensions/?include_text=3D1 - section 2.1 + = 2.2 : > Length > This field is identical to the Length field of the Attribute > format defined in [RFC2865] Section 5. > >=20 >=20 > Best Regards, > Leaf >=20 >=20 > -----Original Message----- > From: Bernie Volz (volz) [mailto:volz@cisco.com]=20 > Sent: Tuesday, October 23, 2012 7:34 PM > To: Leaf yeh > Cc: dhcwg@ietf.org; Tomek Mrugalski > Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-03.txt >=20 >>> Bernie - In section 4, please indicate that the "one or a list of RADIU= S Attributes" are encoded in RADIUS "format" and that this uses a 8-bit typ= e and length and that the length includes the length octet? >>>=20 >>> Editorial. The format of the RADIUS attribute in the traditional type s= pace is defined in section 5 of RFC2865. The format of the RADIUS attribute= in the extended type space is defined in section 2 of draft-ietf-radext-ra= dius-extensions. The definition of their 'Length' field are identical for t= he length of the whole attribute including the TLV fields of 'Type', 'Lengt= h', 'Value' and/or 'Extended-Type', 'M-flag', 'Reserved'. I'd like OPTION_R= ADIUS could also include the attributes defined in the future which employe= d the extended type space, but have no objection to your suggestion for the= clarification on the 'length' field of RADIUS attribute. >=20 > Sent from my iPad >=20 > On Oct 23, 2012, at 7:33 AM, "Leaf yeh" wrote: >=20 >> Bernie - For issue about Radius attributes... >>=20 >> What do you mean for the 'issue'?=20 >>=20 >>=20 >> Best Regards, >> Leaf >>=20 >>=20 >> -----Original Message----- >> From: Bernie Volz (volz) [mailto:volz@cisco.com]=20 >> Sent: Tuesday, October 23, 2012 7:28 PM >> To: Leaf yeh >> Cc: Gaurav Halwasia (ghalwasi); dhcwg@ietf.org; Tomek Mrugalski >> Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-03.txt >>=20 >> For issue about Radius attributes, why not just include those cross refe= rences? >>=20 >> Sent from my iPad >>=20 >> On Oct 23, 2012, at 5:58 AM, "Leaf yeh" wrote: >>=20 >>> Hi Bernie, >>>=20 >>> Thanks for your valuable comments. >>>=20 >>> Bernie - In section 4, please indicate that the "one or a list of RADIU= S Attributes" are encoded in RADIUS "format" and that this uses a 8-bit typ= e and length and that the length includes the length octet? >>>=20 >>> Editorial. The format of the RADIUS attribute in the traditional type s= pace is defined in section 5 of RFC2865. The format of the RADIUS attribute= in the extended type space is defined in section 2 of draft-ietf-radext-ra= dius-extensions. The definition of their 'Length' field are identical for t= he length of the whole attribute including the TLV fields of 'Type', 'Lengt= h', 'Value' and/or 'Extended-Type', 'M-flag', 'Reserved'. I'd like OPTION_R= ADIUS could also include the attributes defined in the future which employe= d the extended type space, but have no objection to your suggestion for the= clarification on the 'length' field of RADIUS attribute.=20 >>>=20 >>> How about add a note after the table as follows: 'Note: The one-octet '= Length' field in the RADIUS attribute indicates the length of the whole att= ribute.' ? >>>=20 >>>=20 >>> Bernie - Looks like the text "As the same method in [RFC4014], ..." has= been replaced with the text mentioned below? Good if that is the case as I= am not sure what "same method" really meant. Please also drop "Note: The a= bove table might have more attributes to join in the future." if that wasn'= t already done. >>>=20 >>> Editorial. I am fine to drop the text of ' As the same method in [RFC40= 14],' and 'Note: The above table might have more attributes to join in the = future.' >>>=20 >>>=20 >>> Bernie - So, I don't see a need to require this MUST and I think you sh= ould be silent about it -- I would thus just remove the last sentence of th= e paragraph in section 5. >>>=20 >>> Editorial. Accepted if ERO (43) sounds a concern. >>>=20 >>>=20 >>> Bernie - Should either be dropped or changed to read: >>>=20 >>> Editorial. I tend to drop the last sentence in section 6, because I hav= e not seen the use case (or necessity) to introduce ERO (43) here. >>>=20 >>>=20 >>> Best Regards, >>> Leaf >>>=20 >>>=20 >>>=20 >>> -----Original Message----- >>> From: Bernie Volz (volz) [mailto:volz@cisco.com]=20 >>> Sent: Monday, October 22, 2012 11:25 PM >>> To: Gaurav Halwasia (ghalwasi); Leaf yeh; dhcwg@ietf.org >>> Cc: Tomek Mrugalski >>> Subject: RE: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-03.tx= t >>>=20 >>> Hi: >>>=20 >>> In general this looks very good now. And, I (mostly) agree with the cha= nges proposed. >>>=20 >>> I would suggest the following minor changes: >>>=20 >>> - In section 4, please indicate that the "one or a list of RADIUS Attri= butes" are encoded in RADIUS "format" and that this uses a 8-bit type and l= ength and that the length includes the length octet? >>>=20 >>> - Looks like the text "As the same method in [RFC4014], ..." has been r= eplaced with the text mentioned below? Good if that is the case as I am not= sure what "same method" really meant. Please also drop "Note: The above ta= ble might have more attributes to join in the future." if that wasn't alrea= dy done. >>>=20 >>> I believe that future RADIUS Attribute documents can update this docume= nt if the attribute(s) are to be allowed in this option in the future. Perh= aps IANA could maintain a registry of the RADIUS attributes allowed in the = option; but I don't think we requested this for v4 and not sure it is reall= y needed for v6. >>>=20 >>> - Regarding ... how about ''The relay agent MUST silently discard OPTIO= N_RADIUS if received in the RELAY-REPL (13) message." >>>=20 >>> Do you really want to specify this? The server is not supposed to echo = back options. BUT we do have the Echo Request Option (ERO, 43) which a rela= y could use to request this information back if it needed it for some reaso= n. So, I don't see a need to require this MUST and I think you should be si= lent about it -- I would thus just remove the last sentence of the paragrap= h in section 5. >>>=20 >>> Though we also should fix the text in 6. Server Behavior. The last sent= ence of: >>>=20 >>> The DHCPv6 server MUST NOT include OPTION_RADIUS in RELAY-REPL (13) mes= sages. >>>=20 >>> Should either be dropped or changed to read: >>>=20 >>> The DHCPv6 server MUST NOT include the OPTION_RADIUS in RELAY-REPL (13)= messages unless requested by the relay agent in the Echo Request Option (O= PTION_ERO). >>>=20 >>> - Bernie >>>=20 >>>=20 >>> -----Original Message----- >>> From: Gaurav Halwasia (ghalwasi)=20 >>> Sent: Monday, October 22, 2012 8:48 AM >>> To: Leaf yeh; dhcwg@ietf.org >>> Cc: Bernie Volz (volz); Tomek Mrugalski >>> Subject: RE: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-03.tx= t >>>=20 >>> Gaurav - * Section 4 heading could say "DHCPv6 OPTION_RADIUS option" >>> Editorial. How about "DHCPv6 RADIUS option"?=20 >>> [Gaurav] Yes, this looks good as well. Just "OPTION_RADIUS" was looking= odd. >>>=20 >>> Gaurav - * Section 4 says, " only the attributes listed in the table be= low may be included in the OPTION_RADIUS ". What about any other attributes= which might be required in future.? Are you suggesting that a new specific= ation will be required to include any other attribute in DHCPv6 RADIUS_OPTI= ON option.? IMO, keeping the attribute list open for the implementer will = increase the usability of this mechanism. I think this specification can ju= st mention the attributes as one of the use-case.=20 >>>=20 >>> Editorial. I adopted the roughly same text in my draft as that in the s= ection 4 of RFC4014. >>>=20 >>> To avoid dependencies between the address allocation and other s= tate >>> information between the RADIUS server and the DHCP server, the DHCP >>> relay agent SHOULD include only the attributes in the table below in >>> an instance of the RADIUS Attributes suboption. >>>=20 >>> I need consult with the chair to work out a solution for your concern. >>> [Gaurav] I understand you have borrowed this text from RFC4014. But I s= till think that keeping the attribute space unrestricted will be good. Any= how, let me know when you arrive at any conclusion regarding this based upo= n your discussion with chair. >>>=20 >>> Gaurav -* Section 5, "Relay Agent Behavior" says " The relay agent MUST= silently discard OPTION_RADIUS >>> if received. ". Can you explain about it little more and what is your p= roposal keeping "Relay Chaining" in mind.? >>>=20 >>> Technical. Good point. How about ''The relay agent MUST silently discar= d OPTION_RADIUS if received in the RELAY-REPL (13) message."=20 >>> [Gaurav] I am fine with this text. >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg From leaf.yeh.sdo@gmail.com Tue Oct 23 07:04:19 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1045A21F8654 for ; Tue, 23 Oct 2012 07:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HS_INDEX_PARAM=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 PYZzY3G5nNTB for ; Tue, 23 Oct 2012 07:04:18 -0700 (PDT) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 08EFD21F8578 for ; Tue, 23 Oct 2012 07:04:17 -0700 (PDT) Received: by mail-da0-f44.google.com with SMTP id h15so1933735dan.31 for ; Tue, 23 Oct 2012 07:04:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=lAiNE6bn6oUl7WjKTLXcvXLFg10HqfKM2N2ju1dZO30=; b=QcKb7Zfj1nwnJ5uRoSnmpP5oeE/ruYMjf44AVCZWm3TmtkshXNo6/+wyRXFpDKJw8H R2nj44vckfdJMrPCHFB0HmEKi4Y9Wf3UsHH0WzmrI+egkVqSgk6Ho9MV8FrmXMnOFPjx nkG7PhaLA183Sg6RKyTN6dfbyoBaHs+FZ3tLsKa/qbSlF3ABJ3yIHQUinDrMJXGs5n0x TRkTRnGTYBqWqs+DJkBgg3uSS56DAC8uvUqlKC02DBPNnVMf9yL2RgjTMz7Lz4EdKSQP OgbQIWdIeciAaw3O7isDfv2RCCkaKs3WmdGZz/GNrqDIAtFwKQLqnzH/wTYEHA+cTpnS cNFA== Received: by 10.68.129.72 with SMTP id nu8mr40329161pbb.29.1351001057717; Tue, 23 Oct 2012 07:04:17 -0700 (PDT) Received: from lst9242355d22a ([14.153.102.32]) by mx.google.com with ESMTPS id a10sm7754244paz.35.2012.10.23.07.04.12 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 23 Oct 2012 07:04:16 -0700 (PDT) From: "Leaf Yeh" To: "'Bernie Volz \(volz\)'" References: <20121022023022.31796.83986.idtracker@ietfa.amsl.com> <90903C21C73202418A48BFBE80AEE5EB1BD89EEA@xmb-aln-x06.cisco.com> <90903C21C73202418A48BFBE80AEE5EB1BD8BA7C@xmb-aln-x06.cisco.com> <489D13FBFA9B3E41812EA89F188F018E0F544231@xmb-rcd-x04.cisco.com>, , , In-Reply-To: Date: Tue, 23 Oct 2012 22:04:07 +0800 Message-ID: <5086a3e0.aa54420a.3acd.ffffb254@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHNr/1HNSd5KF2CtUyzfSel6RTWmJfEmrcQgACfTICAAFvHAIAABPuA///T6ACAAY7HgP//xXtegABVVAD//6x7HQAK0pWA///E2+v///cDQA== Content-Language: zh-cn Cc: dhcwg@ietf.org Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-03.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 14:04:19 -0000 3rd - How about 'Note: The definition of the RADIUS attribute's 'Length' field in section 5 of RFC2865 is different from that of DHCPv6 option's option-length field defined here.' ? Best Regards, Leaf -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz) Sent: Tuesday, October 23, 2012 9:13 PM To: Leaf yeh Cc: dhcwg@ietf.org; Tomek Mrugalski Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-03.txt I don't like "whole attribute" ... What does that mean? It may be best to just ref the Radius documents. Perhaps a note that "While RADIUS uses TLV encoding for attributes as DHCP does for options, the L (length) for RADIUS attributes is defined differently than for DHCP options." Sent from my iPad On Oct 23, 2012, at 7:45 AM, "Leaf yeh" wrote: > How about add a note after the table in section 4 as follows: 'Note: The one-octet 'Length' field in the RADIUS attribute defined in section 5 of RFC2865, indicates the length of the whole attribute' ? > > > draft-ietf-radext-radius-extensions @ http://datatracker.ietf.org/doc/draft-ietf-radext-radius-extensions/?include _text=1 - section 2.1 + 2.2 : > Length > This field is identical to the Length field of the Attribute > format defined in [RFC2865] Section 5. > > > > Best Regards, > Leaf > > > -----Original Message----- > From: Bernie Volz (volz) [mailto:volz@cisco.com] > Sent: Tuesday, October 23, 2012 7:34 PM > To: Leaf yeh > Cc: dhcwg@ietf.org; Tomek Mrugalski > Subject: Re: [dhcwg] I-D Action: > draft-ietf-dhc-dhcpv6-radius-opt-03.txt > >>> Bernie - In section 4, please indicate that the "one or a list of RADIUS Attributes" are encoded in RADIUS "format" and that this uses a 8-bit type and length and that the length includes the length octet? >>> >>> Editorial. The format of the RADIUS attribute in the traditional type space is defined in section 5 of RFC2865. The format of the RADIUS attribute in the extended type space is defined in section 2 of draft-ietf-radext-radius-extensions. The definition of their 'Length' field are identical for the length of the whole attribute including the TLV fields of 'Type', 'Length', 'Value' and/or 'Extended-Type', 'M-flag', 'Reserved'. I'd like OPTION_RADIUS could also include the attributes defined in the future which employed the extended type space, but have no objection to your suggestion for the clarification on the 'length' field of RADIUS attribute. > > Sent from my iPad > > On Oct 23, 2012, at 7:33 AM, "Leaf yeh" wrote: > >> Bernie - For issue about Radius attributes... >> >> What do you mean for the 'issue'? >> >> >> Best Regards, >> Leaf >> >> >> -----Original Message----- >> From: Bernie Volz (volz) [mailto:volz@cisco.com] >> Sent: Tuesday, October 23, 2012 7:28 PM >> To: Leaf yeh >> Cc: Gaurav Halwasia (ghalwasi); dhcwg@ietf.org; Tomek Mrugalski >> Subject: Re: [dhcwg] I-D Action: >> draft-ietf-dhc-dhcpv6-radius-opt-03.txt >> >> For issue about Radius attributes, why not just include those cross references? >> >> Sent from my iPad >> >> On Oct 23, 2012, at 5:58 AM, "Leaf yeh" wrote: >> >>> Hi Bernie, >>> >>> Thanks for your valuable comments. >>> >>> Bernie - In section 4, please indicate that the "one or a list of RADIUS Attributes" are encoded in RADIUS "format" and that this uses a 8-bit type and length and that the length includes the length octet? >>> >>> Editorial. The format of the RADIUS attribute in the traditional type space is defined in section 5 of RFC2865. The format of the RADIUS attribute in the extended type space is defined in section 2 of draft-ietf-radext-radius-extensions. The definition of their 'Length' field are identical for the length of the whole attribute including the TLV fields of 'Type', 'Length', 'Value' and/or 'Extended-Type', 'M-flag', 'Reserved'. I'd like OPTION_RADIUS could also include the attributes defined in the future which employed the extended type space, but have no objection to your suggestion for the clarification on the 'length' field of RADIUS attribute. >>> >>> How about add a note after the table as follows: 'Note: The one-octet 'Length' field in the RADIUS attribute indicates the length of the whole attribute.' ? >>> >>> >>> Bernie - Looks like the text "As the same method in [RFC4014], ..." has been replaced with the text mentioned below? Good if that is the case as I am not sure what "same method" really meant. Please also drop "Note: The above table might have more attributes to join in the future." if that wasn't already done. >>> >>> Editorial. I am fine to drop the text of ' As the same method in [RFC4014],' and 'Note: The above table might have more attributes to join in the future.' >>> >>> >>> Bernie - So, I don't see a need to require this MUST and I think you should be silent about it -- I would thus just remove the last sentence of the paragraph in section 5. >>> >>> Editorial. Accepted if ERO (43) sounds a concern. >>> >>> >>> Bernie - Should either be dropped or changed to read: >>> >>> Editorial. I tend to drop the last sentence in section 6, because I have not seen the use case (or necessity) to introduce ERO (43) here. >>> >>> >>> Best Regards, >>> Leaf >>> >>> >>> >>> -----Original Message----- >>> From: Bernie Volz (volz) [mailto:volz@cisco.com] >>> Sent: Monday, October 22, 2012 11:25 PM >>> To: Gaurav Halwasia (ghalwasi); Leaf yeh; dhcwg@ietf.org >>> Cc: Tomek Mrugalski >>> Subject: RE: [dhcwg] I-D Action: >>> draft-ietf-dhc-dhcpv6-radius-opt-03.txt >>> >>> Hi: >>> >>> In general this looks very good now. And, I (mostly) agree with the changes proposed. >>> >>> I would suggest the following minor changes: >>> >>> - In section 4, please indicate that the "one or a list of RADIUS Attributes" are encoded in RADIUS "format" and that this uses a 8-bit type and length and that the length includes the length octet? >>> >>> - Looks like the text "As the same method in [RFC4014], ..." has been replaced with the text mentioned below? Good if that is the case as I am not sure what "same method" really meant. Please also drop "Note: The above table might have more attributes to join in the future." if that wasn't already done. >>> >>> I believe that future RADIUS Attribute documents can update this document if the attribute(s) are to be allowed in this option in the future. Perhaps IANA could maintain a registry of the RADIUS attributes allowed in the option; but I don't think we requested this for v4 and not sure it is really needed for v6. >>> >>> - Regarding ... how about ''The relay agent MUST silently discard OPTION_RADIUS if received in the RELAY-REPL (13) message." >>> >>> Do you really want to specify this? The server is not supposed to echo back options. BUT we do have the Echo Request Option (ERO, 43) which a relay could use to request this information back if it needed it for some reason. So, I don't see a need to require this MUST and I think you should be silent about it -- I would thus just remove the last sentence of the paragraph in section 5. >>> >>> Though we also should fix the text in 6. Server Behavior. The last sentence of: >>> >>> The DHCPv6 server MUST NOT include OPTION_RADIUS in RELAY-REPL (13) messages. >>> >>> Should either be dropped or changed to read: >>> >>> The DHCPv6 server MUST NOT include the OPTION_RADIUS in RELAY-REPL (13) messages unless requested by the relay agent in the Echo Request Option (OPTION_ERO). >>> >>> - Bernie >>> >>> >>> -----Original Message----- >>> From: Gaurav Halwasia (ghalwasi) >>> Sent: Monday, October 22, 2012 8:48 AM >>> To: Leaf yeh; dhcwg@ietf.org >>> Cc: Bernie Volz (volz); Tomek Mrugalski >>> Subject: RE: [dhcwg] I-D Action: >>> draft-ietf-dhc-dhcpv6-radius-opt-03.txt >>> >>> Gaurav - * Section 4 heading could say "DHCPv6 OPTION_RADIUS option" >>> Editorial. How about "DHCPv6 RADIUS option"? >>> [Gaurav] Yes, this looks good as well. Just "OPTION_RADIUS" was looking odd. >>> >>> Gaurav - * Section 4 says, " only the attributes listed in the table below may be included in the OPTION_RADIUS ". What about any other attributes which might be required in future.? Are you suggesting that a new specification will be required to include any other attribute in DHCPv6 RADIUS_OPTION option.? IMO, keeping the attribute list open for the implementer will increase the usability of this mechanism. I think this specification can just mention the attributes as one of the use-case. >>> >>> Editorial. I adopted the roughly same text in my draft as that in the section 4 of RFC4014. >>> >>> To avoid dependencies between the address allocation and >>> other state information between the RADIUS server and the DHCP >>> server, the DHCP relay agent SHOULD include only the attributes in >>> the table below in an instance of the RADIUS Attributes >>> suboption. >>> >>> I need consult with the chair to work out a solution for your concern. >>> [Gaurav] I understand you have borrowed this text from RFC4014. But I still think that keeping the attribute space unrestricted will be good. Anyhow, let me know when you arrive at any conclusion regarding this based upon your discussion with chair. >>> >>> Gaurav -* Section 5, "Relay Agent Behavior" says " The relay agent >>> MUST silently discard OPTION_RADIUS if received. ". Can you explain about it little more and what is your proposal keeping "Relay Chaining" in mind.? >>> >>> Technical. Good point. How about ''The relay agent MUST silently discard OPTION_RADIUS if received in the RELAY-REPL (13) message." >>> [Gaurav] I am fine with this text. >> _______________________________________________ >> 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 Ted.Lemon@nominum.com Tue Oct 23 20:08:59 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40B5B1F0C7E for ; Tue, 23 Oct 2012 20:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.505 X-Spam-Level: X-Spam-Status: No, score=-106.505 tagged_above=-999 required=5 tests=[AWL=0.094, 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 QV1r6re33tB4 for ; Tue, 23 Oct 2012 20:08:58 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id 425BE1F0C67 for ; Tue, 23 Oct 2012 20:08:56 -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 DSNKUIdbw4Hy/jj7/6eqbtVK/1u+swC5nuKp@postini.com; Tue, 23 Oct 2012 20:08: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 7A3F41B83C0 for ; Tue, 23 Oct 2012 19:32:50 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 7017319005C for ; Tue, 23 Oct 2012 19:32:50 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Tue, 23 Oct 2012 19:32:45 -0700 From: Ted Lemon To: " WG" Thread-Topic: [dhcwg] Call for Agenda Items for IETF 85 Thread-Index: AQHNrSzAWipHGI0lGEuQGqDJlDmLCpfIOq+A Date: Wed, 24 Oct 2012 02:32:44 +0000 Message-ID: <9FFFC22E-A49F-435F-A94D-B58A9928CA4E@nominum.com> References: <2642448B-3789-4D93-93BE-90AB36C081D7@nominum.com> In-Reply-To: <2642448B-3789-4D93-93BE-90AB36C081D7@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] Call for Agenda Items for IETF 85 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, 24 Oct 2012 03:08:59 -0000 On Oct 18, 2012, at 8:33 AM, Ted Lemon wrote: > Folks, if you plan on presenting anything to the working group in Atlanta= , please send us your agenda items ASAP. We would like to have your slid= es by the 31st of October. I just uploaded the agenda. It's rather short. If you think your presen= tation should be on it, please check to see that it is. Thanks! From liu.guoyan@zte.com.cn Tue Oct 23 20:31:44 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4684F11E8115 for ; Tue, 23 Oct 2012 20:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 9as3bqkvm3v7 for ; Tue, 23 Oct 2012 20:31:43 -0700 (PDT) Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 7D70111E80D3 for ; Tue, 23 Oct 2012 20:31:43 -0700 (PDT) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id 2A8F61252AF3; Wed, 24 Oct 2012 11:32:37 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q9O3VYCU047452; Wed, 24 Oct 2012 11:31:34 +0800 (GMT-8) (envelope-from liu.guoyan@zte.com.cn) In-Reply-To: To: dhcwg@ietf.org MIME-Version: 1.0 X-KeepSent: 47C9D31C:048F22E2-48257AA1:0010D67E; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: liu.guoyan@zte.com.cn Date: Wed, 24 Oct 2012 11:31:25 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-10-24 11:31:32, Serialize complete at 2012-10-24 11:31:32 Content-Type: multipart/alternative; boundary="=_alternative 00135F6A48257AA1_=" X-MAIL: mse02.zte.com.cn q9O3VYCU047452 Cc: Daniel.Derksen@alcatel-lucent.com, zhu.chunhui@zte.com.cn, tu.yangwei@zte.com.cn Subject: [dhcwg] [DHC] Request for comments on draft-liu-dhc-3gpp-option-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, 24 Oct 2012 03:31:44 -0000 This is a multipart message in MIME format. --=_alternative 00135F6A48257AA1_= Content-Type: text/plain; charset="US-ASCII" Dear all, We have submitted a new version of draft-liu-dhc-3gpp-option, and you can find the URL(http://www.ietf.org/id/draft-liu-dhc-3gpp-option-02.txt). This draft was previously presented in the IETF 83# meeting.And Now, we update the option's format for DHCPv4 and DHCPv6 separately. Please kindly provide your comments and suggestions, and your help will be truly appreciated. BR, Guoyan Liu -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s). If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited. If you have received this mail in error, please delete it and notify us immediately. --=_alternative 00135F6A48257AA1_= Content-Type: text/html; charset="US-ASCII"
Dear all,
We have submitted a new version of draft-liu-dhc-3gpp-option, and you can find the URL(http://www.ietf.org/id/draft-liu-dhc-3gpp-option-02.txt).
This draft was previously presented in the IETF 83# meeting.And Now, we update the option's format for DHCPv4 and DHCPv6 separately.
Please kindly provide your comments and suggestions, and your help will be truly appreciated.

BR,

Guoyan Liu 


--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.

--=_alternative 00135F6A48257AA1_=-- From volz@cisco.com Wed Oct 24 12:18:58 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4484621F885A for ; Wed, 24 Oct 2012 12:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.373 X-Spam-Level: X-Spam-Status: No, score=-10.373 tagged_above=-999 required=5 tests=[AWL=0.226, 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 Xn4tu8hcSCav for ; Wed, 24 Oct 2012 12:18:57 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 96C0C21F8732 for ; Wed, 24 Oct 2012 12:18:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2345; q=dns/txt; s=iport; t=1351106337; x=1352315937; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=+crSIpn2/Y5AvH63tRS4i6TVBPvzbV5pY7sIyMGge/s=; b=jjpXFYenU+/oqmlfqtS+DyhGdNgW44jbERma+IgQIvFqkkq1bRvXueJU BamCoHEgm8m+1ssfF/DM6vTIRMAXV3uqnWbCWvEznJxw2k2XH5ADWrDzm uih18RBnFrmOSPi9aV1BXozLCrH8iGjUZySkF2PjyCFBqqY8zq+kk2lQh s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAOI9iFCtJV2b/2dsb2JhbABEwXqBCIIeAQEBBAEBAQ8BJzQLDAQCAQgRBAEBAQoUCQcnCxQJCAIEDgUIGodiC5xKoBAEi2GGDGEDpEGBa4JvgVsHGR4 X-IronPort-AV: E=Sophos;i="4.80,642,1344211200"; d="scan'208";a="134975010" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-2.cisco.com with ESMTP; 24 Oct 2012 19:18:57 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q9OJIuSD007678 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 24 Oct 2012 19:18:57 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.200]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.001; Wed, 24 Oct 2012 14:18:56 -0500 From: "Bernie Volz (volz)" To: Ted Lemon Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-02.txt Thread-Index: AQHNsGzT0FyP5oOW+E6ucf5QkY1WfJfFeQ0QgABgngCAAE3CgIACr2NQ Date: Wed, 24 Oct 2012 19:18:56 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E0F54792A@xmb-rcd-x04.cisco.com> References: <20121022154839.6058.71568.idtracker@ietfa.amsl.com> <489D13FBFA9B3E41812EA89F188F018E0F544358@xmb-rcd-x04.cisco.com> <353D80BF-2100-4570-8089-139ADBB596F5@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F545298@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E0F545298@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.254.17] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19302.000 x-tm-as-result: No--44.998600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-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, 24 Oct 2012 19:18:58 -0000 I missed the submission deadline so this will have to wait until things ope= n up again. I will not be at the IETF 85 meeting (will be away on vacation). Doesn't look like Ole submitted a request for time on the agenda; not sure = if it is needed - hopefully document can go to last call with the 03 versio= n after submissions reopen. - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of B= ernie Volz (volz) Sent: Monday, October 22, 2012 10:22 PM To: Ted Lemon Cc: dhcwg@ietf.org Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-02.t= xt I will update, but will revise to make it clear this is for Solicit/Adverti= se. Reply semantics aren't the same. How about: To clarify further: when a client requests both IA_NA and IA_PD, and the se= rver can offer IA_PD but not IA_NA, the server sends an Advertise response = containing no IA_NA option, a status code option of NoAddrsAvail, and one o= r more IA_PD options containing IAPREFIX options. - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= ed Lemon Sent: Monday, October 22, 2012 12:36 PM To: Bernie Volz (volz) Cc: dhcwg@ietf.org Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-02.t= xt On Oct 22, 2012, at 11:57 AM, Bernie Volz (volz) wrote: > To clarify further: the expected Advertise message from a server when > a client requests both address assignment (IA_NA) and prefix > delegation (IA_PD) and the server can only delegate prefixes, is a > Status Code Option with the NoAddrsAvail status code, no IA_NA > option(s), and the IA_PD option(s) with IAPREFIX option(s). Difficult to parse. How about: To clarify further: when a client requests both IA_NA and IA_PD, and the se= rver can offer IA_PD but not IA_NA, the server should send a response conta= ining no IA_NA, a status code of NoAddrsAvail, and one or more IA_PD option= s containing IA_PREFIX options. _______________________________________________ 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 otroan@employees.org Thu Oct 25 00:20:59 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AFF921F9079 for ; Thu, 25 Oct 2012 00:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.269 X-Spam-Level: X-Spam-Status: No, score=-10.269 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 xTzq-MfXvBDf for ; Thu, 25 Oct 2012 00:20:58 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id F103C21F9076 for ; Thu, 25 Oct 2012 00:20:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,645,1344211200"; d="scan'208";a="77737533" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 25 Oct 2012 07:20:56 +0000 Received: from [10.148.10.39] ([10.148.10.39]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9P7Ktoa025368 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 25 Oct 2012 07:20:56 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E0F54792A@xmb-rcd-x04.cisco.com> Date: Thu, 25 Oct 2012 09:20:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121022154839.6058.71568.idtracker@ietfa.amsl.com> <489D13FBFA9B3E41812EA89F188F018E0F544358@xmb-rcd-x04.cisco.com> <353D80BF-2100-4570-8089-139ADBB596F5@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F545298@xmb-rcd-x04.cisco.com> <489D13FBFA9B3E41812EA89F188F018E0F54792A@xmb-rcd-x04.cisco.com> To: Bernie Volz (volz) X-Mailer: Apple Mail (2.1498) Cc: "dhcwg@ietf.org" , Ted Lemon Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-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, 25 Oct 2012 07:20:59 -0000 > I missed the submission deadline so this will have to wait until = things open up again. >=20 > I will not be at the IETF 85 meeting (will be away on vacation). >=20 > Doesn't look like Ole submitted a request for time on the agenda; not = sure if it is needed - hopefully document can go to last call with the = 03 version after submissions reopen. that was my sentiment too. unless the chairs think there are issues with this document that would = benefit some face time? cheers, Ole= From Ted.Lemon@nominum.com Thu Oct 25 04:36:12 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 429DC21F899F for ; Thu, 25 Oct 2012 04:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.356 X-Spam-Level: X-Spam-Status: No, score=-106.356 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 ztaDA9BGsE9s for ; Thu, 25 Oct 2012 04:36:11 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id A7BB121F8928 for ; Thu, 25 Oct 2012 04:36:11 -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 DSNKUIkkK4jfhyBQRljCEkibUX6N4bIrP2zG@postini.com; Thu, 25 Oct 2012 04:36: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 C2B201B83C1 for ; Thu, 25 Oct 2012 04:36:10 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id B607B19005C; Thu, 25 Oct 2012 04:36:10 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Thu, 25 Oct 2012 04:36:10 -0700 From: Ted Lemon To: =?iso-8859-1?Q?Ole_Tr=F8an?= Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-02.txt Thread-Index: AQHNsGzRKG67f1J1W0CWFbh/9n68J5fF8ICAgAAKsgCAAKO0gIACrmsAgADJuYCAAEdOAA== Date: Thu, 25 Oct 2012 11:36:09 +0000 Message-ID: <4DA0ADEB-60D5-4399-A6E2-52787001F6B4@nominum.com> References: <20121022154839.6058.71568.idtracker@ietfa.amsl.com> <489D13FBFA9B3E41812EA89F188F018E0F544358@xmb-rcd-x04.cisco.com> <353D80BF-2100-4570-8089-139ADBB596F5@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F545298@xmb-rcd-x04.cisco.com> <489D13FBFA9B3E41812EA89F188F018E0F54792A@xmb-rcd-x04.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <0015553B7134F442915111D2B9B0FCD1@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , Bernie Volz Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-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, 25 Oct 2012 11:36:12 -0000 On Oct 25, 2012, at 3:20 AM, Ole Tr=F8an wrote: > unless the chairs think there are issues with this document that would be= nefit some face time? It's up to you guys. We have time on the agenda at the moment if you want= it, but no pressure.