From Ted.Lemon@nominum.com Thu Nov 1 06:04:18 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 4A7CB21F8AAC for ; Thu, 1 Nov 2012 06:04:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lvqt2xWn9grj for ; Thu, 1 Nov 2012 06:04:17 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 89B6121F8AD2 for ; Thu, 1 Nov 2012 06:04:17 -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 DSNKUJJzUWnZehrGpxhIXYHiJoxfhXAcDKMq@postini.com; Thu, 01 Nov 2012 06:04:17 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 B0FC21B8355 for ; Thu, 1 Nov 2012 06:04:16 -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 A5B9119005C for ; Thu, 1 Nov 2012 06:04:16 -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, 1 Nov 2012 06:04:16 -0700 From: Ted Lemon To: "dhcwg@ietf.org WG" Thread-Topic: Request for help from NomCom Thread-Index: AQHNuDFl2/Yi1Zgev0K7Fr2G+aE3cA== Date: Thu, 1 Nov 2012 13:04:15 +0000 Message-ID: <66BAAD68-FCF3-47DE-93D9-A9D1F6F76E55@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] Request for help from NomCom X-BeenThere: dhcwg@ietf.org 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, 01 Nov 2012 13:04:18 -0000 The IETF Nominations Committee (NomCom) continues to seek input from the IETF Community. The NomCom would greatly appreciate any help you could provide in making members of your working group aware of ways in which they can provide valuable feedback to the NomCom. In order to ensure that your input is received in time to be useful, the=20 NomCom needs to receive community feedback on or before Sunday, November 11= . The final list of candidates (as per RFC 5680) that the NomCom is=20 considering for open positions can be found at:=20 https://www.ietf.org/group/nomcom/2012/input/ The NomCom will be holding office hours during IETF 85, Monday- Thursday from 1:00pm to 3:00pm in Room 305. The NomCom welcomes=20 comments on specific individuals, as well as general feedback related to=20 any of the positions that NomCom is considering. Note: A list of leadership positions that the NomCom is considering can be= =20 found at: https://www.ietf.org/group/nomcom/2012/ If the NomCom office hours are inconvenient for you or if you cannot=20 attend IETF 85, the NomCom is happy to take community input via email=20 to nomcom12 at ietf.org. Additionally, the NomCom is happy to arrange a=20 meeting outside of office hours, just send us email and we can set=20 something up. Comments on specific candidates can also be provided to the NomCom via the web feedback tool:=20 https://www.ietf.org/group/nomcom/2012/input/ Thank you for your help, - Matt Lepinski nomcom-chair at ietf.org From tomasz.mrugalski@gmail.com Sun Nov 4 00:28: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 A603521F8451 for ; Sun, 4 Nov 2012 00:28:52 -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 o6MRj67tXD9F for ; Sun, 4 Nov 2012 00:28:52 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id D69F421F8452 for ; Sun, 4 Nov 2012 00:28:51 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so3700232lam.31 for ; Sun, 04 Nov 2012 00:28:50 -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:x-enigmail-version:content-type :content-transfer-encoding; bh=KIX6k7yLowYo4z5Gi7jL6OdcaaMExr2dAaAYUv9WRu8=; b=c1uUZNUl5kUAXhTHsgQZxnlLwpO5AXB/ynvfyxGseWbYQQ+idfHiZPuWg9OJznL3UV mafRdDhPBfJrJV0+6REHSeJM98v8QsHoY6kaNY8Evo8MAha1MXprxjqVMScR1prtRu8L te+cBEwrGD4XCC0/WoX8umSM8lxmV8bSGeJq7xmTTWcfMbfJPDBzeiV/Vo+9iCleqeuS +5ict2cU84FxgRP8rNnR9KrBSFxVI46t+R+QbXQMdgm3H5uS6Etggp9vwXe+Za10PWpO e0+r2NxEZVtNjzTUW6Bqdo8sx5sIXdWREUEYc/YT4+mFM+IYF87WtSmauczmaGPcjUCU sF1g== Received: by 10.112.83.196 with SMTP id s4mr2566718lby.29.1352014130753; Sun, 04 Nov 2012 00:28:50 -0700 (PDT) Received: from tomek.local ([194.182.142.5]) by mx.google.com with ESMTPS id oj5sm4473816lab.8.2012.11.04.00.28.48 (version=SSLv3 cipher=OTHER); Sun, 04 Nov 2012 00:28:49 -0700 (PDT) Message-ID: <5096192D.4020000@gmail.com> Date: Sun, 04 Nov 2012 08:28:45 +0100 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: dhcwg@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [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: Sun, 04 Nov 2012 07:28:52 -0000 On 12-10-22 17:44, Ted Lemon wrote: > 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 document and comment on the list. If > you favor publishing this requirements document, please say so. If > you oppose publishing it, please also say so. The DHC meeting (and possibly end of this WGLC) is just a couple days away. Some time ago over 20 people expressed interest in this work, yet we have not received a single response to that last call. I know that requirement documents may be somewhat boring at times, but without this document moving forward we can't really do useful work on the design document (which haven't received any comments neither). BTW I support this document and would like it to move forward (disclaimer: I'm co author). Cheers, Tomek From sthaug@nethelp.no Sun Nov 4 04:30: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 A44D721F8643 for ; Sun, 4 Nov 2012 04:30:27 -0800 (PST) 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 Nz4BHGRx9JuC for ; Sun, 4 Nov 2012 04:30:27 -0800 (PST) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id A56BD21F8634 for ; Sun, 4 Nov 2012 04:30:26 -0800 (PST) Received: (qmail 64621 invoked from network); 4 Nov 2012 12:30:23 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 4 Nov 2012 12:30:23 -0000 Date: Sun, 04 Nov 2012 13:30:23 +0100 (CET) Message-Id: <20121104.133023.78762705.sthaug@nethelp.no> To: tomasz.mrugalski@gmail.com From: sthaug@nethelp.no In-Reply-To: <5096192D.4020000@gmail.com> References: <5096192D.4020000@gmail.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org Subject: Re: [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: Sun, 04 Nov 2012 12:30:27 -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 document and comment on the list. If > > you favor publishing this requirements document, please say so. If > > you oppose publishing it, please also say so. > The DHC meeting (and possibly end of this WGLC) is just a couple days > away. Some time ago over 20 people expressed interest in this work, yet > we have not received a single response to that last call. > > I know that requirement documents may be somewhat boring at times, but > without this document moving forward we can't really do useful work on > the design document (which haven't received any comments neither). I have read draft-ietf-dhc-dhcpv6-failover-requirements-02 and I support this work going forward. Some comments on the document: - It's possible section 5.6 "Long lived connections" should be expanded. Running DHCPv4 in a failover scenario for our customers, we find that customers really like stable addresses - because it lets them publish names in DNS (DynDNS etc) and run servers. It may also be worth while mentioning that such stable DHCP addresses is an explicit non-goal for some SPs who want to prevent customers from running servers etc. - It may be worth while mentioning that section 6.2 "Synchronization mechanisms" uses concepts from distributed databases, and that some familiarity with distributed databases is useful. - It may be worth while mentioning in section 6.2.1 "Lockstep" that the large performance penalty of this method can be decreased by using SSDs or similar technologies (this is relevant because SSDs are becoming increasingly common). - It may be worth while mentioning in section 8 "DHCPv6 Failover Requirements" points 7 and 8 that such recovery may require manual intervention. Steinar Haug, AS 2116 From ghalwasi@cisco.com Sun Nov 4 17:58: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 9052721F85DD for ; Sun, 4 Nov 2012 17:58:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g8XlrRxhnXor for ; Sun, 4 Nov 2012 17:58:27 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0B37D21F858E for ; Sun, 4 Nov 2012 17:58:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1414; q=dns/txt; s=iport; t=1352080707; x=1353290307; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=gY0E17XgRRW7KtM1ILC9/cZS8arnOZZ792hnw5gCgKc=; b=W0Gxjb1JZf5gLTlDVYD9DX6D4ewBuIjNr5lf+wv7rfkGwS986N8W44Pe 8PxF8myYRzkSJCN2lmvOwCYjQcJoV5p9ySHsxOHrVQAIzNxo1OzS3J0JE um0bLzY1oIDa3DbtxABKEetQaoTTQZ/fnpdWhZkDECClLOVLeJOcKQbmg c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABQdl1CtJXG+/2dsb2JhbABEwzeBCIIeAQEBBAEBAQ8BJzQXBAIBCA4DBAEBAQoUCQcnCxQJCAIEARIIGodoC5linwQEjAGFW2EDpFSBa4Jvghk X-IronPort-AV: E=Sophos;i="4.80,712,1344211200"; d="scan'208";a="138481871" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 05 Nov 2012 01:58:26 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id qA51wQnR008278 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 5 Nov 2012 01:58:26 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.220]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.001; Sun, 4 Nov 2012 19:58:26 -0600 From: "Gaurav Halwasia (ghalwasi)" To: Tomek Mrugalski , "dhcwg@ietf.org" Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-failover-requirements-02 Thread-Index: AQHNsGwoW+LJmw3VLE2UWhN9JpdrFpfZv8iAgADRLdA= Date: Mon, 5 Nov 2012 01:58:25 +0000 Message-ID: <90903C21C73202418A48BFBE80AEE5EB1BDAB836@xmb-aln-x06.cisco.com> References: <5096192D.4020000@gmail.com> In-Reply-To: <5096192D.4020000@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.87.90] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19338.004 x-tm-as-result: No--34.447000-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] 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, 05 Nov 2012 01:58:27 -0000 I support this work/document. Thanks, Gaurav -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= omek Mrugalski Sent: Sunday, November 04, 2012 12:59 PM To: dhcwg@ietf.org Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-failover-requirements-02 On 12-10-22 17:44, Ted Lemon wrote: > 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 document and comment on the list. If > you favor publishing this requirements document, please say so. If > you oppose publishing it, please also say so. The DHC meeting (and possibly end of this WGLC) is just a couple days away.= Some time ago over 20 people expressed interest in this work, yet we have = not received a single response to that last call. I know that requirement documents may be somewhat boring at times, but with= out this document moving forward we can't really do useful work on the desi= gn document (which haven't received any comments neither). BTW I support this document and would like it to move forward (disclaimer: I'm co author). Cheers, Tomek _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From internet-drafts@ietf.org Sun Nov 4 18:04: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 07A1821F87FA; Sun, 4 Nov 2012 18:04:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 Ew0vRksrvm71; Sun, 4 Nov 2012 18:04:01 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9662F21F8853; Sun, 4 Nov 2012 18:04:01 -0800 (PST) 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.35 Message-ID: <20121105020401.14063.18539.idtracker@ietfa.amsl.com> Date: Sun, 04 Nov 2012 18:04:01 -0800 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-client-id-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, 05 Nov 2012 02:04:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Dynamic Host Configuration Working 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-07.txt Pages : 6 Date : 2012-11-04 Abstract: This document updates RFC 2131 -- Dynamic Host Configuration Protocol (DHCP) -- by addressing the issues arising from that document's specification that the server MUST NOT return the '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-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-client-id-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Sun Nov 4 19:22: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 E8ECB21F892A; Sun, 4 Nov 2012 19:22:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, 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 6KAPbJi2OFTs; Sun, 4 Nov 2012 19:22:01 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63F2121F8967; Sun, 4 Nov 2012 19:22:01 -0800 (PST) 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.35 Message-ID: <20121105032201.16769.80085.idtracker@ietfa.amsl.com> Date: Sun, 04 Nov 2012 19:22:01 -0800 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-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, 05 Nov 2012 03:22:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Dynamic Host Configuration Working Group = of the IETF. Title : Issues with multiple stateful DHCPv6 options Author(s) : Ole Troan Bernie Volz Filename : draft-ietf-dhc-dhcpv6-stateful-issues-03.txt Pages : 10 Date : 2012-11-04 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-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-dhcpv6-stateful-issues-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Sun Nov 4 20:19: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 A082B21F89E6; Sun, 4 Nov 2012 20:19:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 m8Yv3yemikYF; Sun, 4 Nov 2012 20:19:25 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C06321F89FF; Sun, 4 Nov 2012 20:19:25 -0800 (PST) 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.35 Message-ID: <20121105041925.10017.22496.idtracker@ietfa.amsl.com> Date: Sun, 04 Nov 2012 20:19:25 -0800 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-04.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 04:19: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 : 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-04.txt Pages : 9 Date : 2012-11-04 Abstract: The DHCPv6 RADIUS option provides a mechanism to exchange authorization and identification information between relay agent and server. This mechanism is meant for 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-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-dhcpv6-radius-opt-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From leaf.y.yeh@huawei.com Sun Nov 4 22:38: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 E94C121F86AF for ; Sun, 4 Nov 2012 22:38:26 -0800 (PST) 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 pAYzmKikdbPf for ; Sun, 4 Nov 2012 22:38:26 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6ACD921F86AD for ; Sun, 4 Nov 2012 22:38:17 -0800 (PST) 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 ALF44170; Mon, 05 Nov 2012 06:38:15 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 5 Nov 2012 06:38:10 +0000 Received: from SZXEML413-HUB.china.huawei.com (10.82.67.152) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 5 Nov 2012 06:38:14 +0000 Received: from SZXEML546-MBX.china.huawei.com ([169.254.3.157]) by szxeml413-hub.china.huawei.com ([10.82.67.152]) with mapi id 14.01.0323.003; Mon, 5 Nov 2012 14:37:58 +0800 From: Leaf yeh To: "dhcwg@ietf.org" Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-04.txt Thread-Index: AQHNuwzUwKvwSJtHG06oTQFI82floZfao/Fw Date: Mon, 5 Nov 2012 06:37:57 +0000 Message-ID: References: <20121105041925.10017.22496.idtracker@ietfa.amsl.com> In-Reply-To: <20121105041925.10017.22496.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-04.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 06:38:27 -0000 Hi folks, Draft (OPTION_RADIUS) has been updated to ver.-04, which solved the editori= al comments from Bernie Volz and Gaurav Halwasia on the ML of DHC.=20 The updates can be found at http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-d= hc-dhcpv6-radius-opt-04 . The meaningful revisions from ver.-03 are:=20 a. suggest to create a new IANA Registry of 'RADIUS Attributes Permitted in= the DHCPv6 RADIUS option' on the same assignment page ( http://www.iana.or= g/assignments/dhcpv6-parameters/dhcpv6-parameters.xml) for the newly define= d OPTION_RADIUS. I believe it could be ready for the WGLC. 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, November 05, 2012 12:19 PM To: i-d-announce@ietf.org Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-04.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-04.txt Pages : 9 Date : 2012-11-04 Abstract: The DHCPv6 RADIUS option provides a mechanism to exchange authorization and identification information between relay agent and server. This mechanism is meant for 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-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-dhcpv6-radius-opt-04 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 Nov 5 06:07: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 A02A821F85F3; Mon, 5 Nov 2012 06:07:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lbbYb4p6cv0X; Mon, 5 Nov 2012 06:07:55 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EC7A21F867F; Mon, 5 Nov 2012 06:07:55 -0800 (PST) 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.35 Message-ID: <20121105140755.31710.59336.idtracker@ietfa.amsl.com> Date: Mon, 05 Nov 2012 06:07:55 -0800 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-cga-config-dhcpv6-04.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 14:07: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 : Configuring Cryptographically Generated Addresses (CGA) = using DHCPv6 Author(s) : Sheng Jiang Sam(Zhongqi) Xia Filename : draft-ietf-dhc-cga-config-dhcpv6-04.txt Pages : 10 Date : 2012-11-05 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 analyzes the parameters required for the generation of CGA from network configuration and management perspective. The configuration procedures of many CGA-relevant parameters with existing mechanisms are described in the document. Only Sec value has no suitable mechanism to be configured by network admin. 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-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-cga-config-dhcpv6-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From kkinnear@cisco.com Mon Nov 5 06:56: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 D758121F8D4B for ; Mon, 5 Nov 2012 06:56:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V2S2qx1O9XBz for ; Mon, 5 Nov 2012 06:56:39 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id A1C6D21F8CF5 for ; Mon, 5 Nov 2012 06:56:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1308; q=dns/txt; s=iport; t=1352127398; x=1353336998; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=5nwnDb+yKzmKTld6Je8f2F0n7Dzzs+yOhZ0pn7EYUUM=; b=WyY5neXA7sUreogr534YVdEPPdcb1d6ee40bZyhOGODGgeCtUO9Sd0UE iUzXV/C7XCf+pLCxuheIyyein0to3Oblrg+so3rByZGBjjlKhlFkME6uq 1RRn1r/j2xM6bvWFuUoOfeBthCOyh7wsqHwafhyab9XJ8D96lbCoN3XKG Y=; X-IronPort-AV: E=Sophos;i="4.80,715,1344211200"; d="scan'208";a="135899005" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP; 05 Nov 2012 14:56:34 +0000 Received: from [161.44.65.117] ([161.44.65.117]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qA5EuYWs030744; Mon, 5 Nov 2012 14:56:34 GMT Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Kim Kinnear In-Reply-To: <5096192D.4020000@gmail.com> Date: Mon, 5 Nov 2012 09:56:44 -0500 Content-Transfer-Encoding: 7bit Message-Id: <0CF49F76-3413-4883-9590-71697EB81922@cisco.com> References: <5096192D.4020000@gmail.com> To: Tomek Mrugalski X-Mailer: Apple Mail (2.1278) Cc: dhcwg@ietf.org, Kim Kinnear Subject: Re: [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, 05 Nov 2012 14:56:40 -0000 I have read this document, and believe that it should move forward. I, too, am a co-author. Regards -- Kim On Nov 4, 2012, at 2:28 AM, Tomek Mrugalski wrote: > On 12-10-22 17:44, Ted Lemon wrote: >> 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 document and comment on the list. If >> you favor publishing this requirements document, please say so. If >> you oppose publishing it, please also say so. > The DHC meeting (and possibly end of this WGLC) is just a couple days > away. Some time ago over 20 people expressed interest in this work, yet > we have not received a single response to that last call. > > I know that requirement documents may be somewhat boring at times, but > without this document moving forward we can't really do useful work on > the design document (which haven't received any comments neither). > > BTW I support this document and would like it to move forward > (disclaimer: I'm co author). > > Cheers, > Tomek > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From list-dhcwg@dragon.net Tue Nov 6 09:51: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 DD8A421F8A8A for ; Tue, 6 Nov 2012 09:51:41 -0800 (PST) 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 lwj1KEW0h3JY for ; Tue, 6 Nov 2012 09:51:41 -0800 (PST) Received: from mail.dragon.net (mail.dragon.net [IPv6:2001:4f8:3:36::235]) by ietfa.amsl.com (Postfix) with ESMTP id D802421F8A10 for ; Tue, 6 Nov 2012 09:51:40 -0800 (PST) Received: from fafnir.remote.dragon.net (localhost [127.0.0.1]) by mail.dragon.net (Postfix) with ESMTP id 8E9693740635 for ; Tue, 6 Nov 2012 09:51:39 -0800 (PST) Received: by fafnir.remote.dragon.net (Postfix, from userid 501) id 4C04B13EF609; Tue, 6 Nov 2012 12:51:39 -0500 (EST) Received: from fafnir.remote.dragon.net (localhost [127.0.0.1]) by fafnir.remote.dragon.net (Postfix) with ESMTP id 492F013EF605 for ; Tue, 6 Nov 2012 12:51:39 -0500 (EST) To: DHCP discussion list From: Paul Ebersman In-reply-to: References: Comments: In-reply-to Ted Lemon message dated "Mon, 22 Oct 2012 15:44:45 -0000." X-Mailer: MH-E 7.4.2; nmh 1.3; XEmacs 21.4 (patch 22) Date: Tue, 06 Nov 2012 12:51:39 -0500 Message-Id: <20121106175139.4C04B13EF609@fafnir.remote.dragon.net> Subject: Re: [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: Tue, 06 Nov 2012 17:51:42 -0000 TLemon> The authors have asked for a last call on the DHCPv6 failover TLemon> requirements draft. This just documents the list of TLemon> requirements for a DHCPv6 failover protocol. If you are TLemon> interested in DHCPv6 failover, please review the document and TLemon> comment on the list. If you favor publishing this requirements TLemon> document, please say so. If you oppose publishing it, please TLemon> also say so. I am in favor of publishing this document. From volz@cisco.com Tue Nov 6 12:49: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 42A2F21F8B07 for ; Tue, 6 Nov 2012 12:49:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uKW5ao5+g25Q for ; Tue, 6 Nov 2012 12:49:39 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 57D3421F84FA for ; Tue, 6 Nov 2012 12:49:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5988; q=dns/txt; s=iport; t=1352234979; x=1353444579; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=jjkt87NUK7dSRkw9cBOYeR7L8QeQqEo7uphZp+YVJ9Q=; b=iUJzol0mXry3m67/NaPk1pcx82nXiqIfi6LcIW5q8mcfF5S2X85q+bc8 tFq8XLGNHvLtyoMPGXbwX9R/tOAAvZDq2RieNkv4gEQL5OlECdOtDgWpn KkcS25ffVR//0y1pcTJDKtRxJ0WrWybT1Wczw4btbdZlU5wVz3qXaKz+R E=; X-IronPort-AV: E=Sophos;i="4.80,723,1344211200"; d="scan'208";a="139241643" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 06 Nov 2012 20:49:39 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id qA6Knc8W014026 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 6 Nov 2012 20:49:38 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.200]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.001; Tue, 6 Nov 2012 14:49:38 -0600 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: draft-ietf-softwire-map-dhcp-01 Thread-Index: Ac28XcM2fI8tpAwuQc2q5rvEH0/zPw== Date: Tue, 6 Nov 2012 20:49:37 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E0F55BAD8@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.245.42] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19344.002 x-tm-as-result: No--38.042100-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: "ot@cisco.com" , "congxiao@cernet.edu.cn" , "Wojciech Dec \(wdec\)" Subject: [dhcwg] draft-ietf-softwire-map-dhcp-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 20:49:40 -0000 Hi: While I can't really comment much on map, I can suggest that the authors re= visit the formatting of the options. So, here goes ... (Outlook might mess = up the diagrams?) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_MAP_RULE | option-length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | prefix6-len | ea-len | prefix4-len | rule-flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | rule-ipv4-prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | rule-ipv6-prefix | | (variable length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . sub-options (variable length) . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Could this be reworked as: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_MAP_RULE | option-length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | prefix6-length| | +-+-+-+-+-+-+-+-+ rule-ipv6-prefix | | (16 octets) | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ea-len | prefix4-len |rule-ipv4-prfx | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | rule-ipv4-prefix (contd) | rule-flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . sub-options (variable length) . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Keep the prefix-length/prefix together and like it was defined in IAPREFI= X. - Keep the subnet-length/subnet together (you can put the length after if y= ou prefer that, but I don't think we have anything that is a good conventio= n for this). - Use fixed length fields UNLESS compressed format is *really* required or = think the savings is worth it. You could make the rule-ipv6-prefix variable= length (but then why not also the rule-ipv4-prefix)? The OPTION_MAP_DMR should reconsider whether to use the compressed prefix (= same arguments). It should definitely be consistent! Refine OPTION_MAP_PORTPARAMS to: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_MAP_PORTPARAMS | option-length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | offset | PSID-len | PSID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The text can say that offset and PSID-len are restricted to specific ranges= . If you ever need something different, a new option can be added instead o= f using the "reserved bits". Also, it would be really helpful if, in the cases were suboptions can exist= , these are identified. While I can understand you might want new ones in t= he future, that's OK. What options exists today? And, are these really suboptions or encapsulated options? In other words, i= s this an option space unique to this option or is this other DHCPv6 option= s (such as the other options defined in this document). I think we've usual= ly used 'encapsulated' to mean the DHCPv6 option space and 'sub-options' to= mean a new option space? Perhaps the examples will help, but I'm unclear what suboptions go into OPT= ION_MAP vs OPTION_MAP_RULE / OPTION_MAP_DMR? There is some information in S= ection 6, DHCPv6 Server Behavior. Perhaps if I knew MAP well, this would be= obvious? Might be nice to rename section 4.1 from "MAP Option" to "MAP Flags Option"= as that is what it is called in much of text? As Tomasz is working on both this draft and the guidelines drafts, perhaps = some of this would be useful to reflect in the guidelines? Using standard b= uilding blocks (such as prefix-length + prefix (either compressed or not)) = would go a long way to make encoding/decoding structured options easier. Sp= litting these fields, as was proposed in the draft, is just making life for= all much more complicated. And, compressing/variable-length vs fixed lengt= h should also be evaluated carefully. Extracting data from a fixed structur= e is a lot easier and less error prone than from a variable one. Yes, bits = over the wire do matter (especially for low-level functionality such as DHC= P because we'd not like to require fragmentation support), but would a boot= level device really need MAP-T? I am not at the IETF meeting the week and sending it to the list as that we= re it should go anyway. - Bernie From leaf.y.yeh@huawei.com Thu Nov 8 00:44:20 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 79BDA21F88A5 for ; Thu, 8 Nov 2012 00:44:20 -0800 (PST) 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 aZyP+QfMHmGq for ; Thu, 8 Nov 2012 00:44:19 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 741B921F888C for ; Thu, 8 Nov 2012 00:44:18 -0800 (PST) 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 AMN54716; Thu, 08 Nov 2012 08:44:17 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 8 Nov 2012 08:44:04 +0000 Received: from SZXEML420-HUB.china.huawei.com (10.82.67.159) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 8 Nov 2012 08:44:16 +0000 Received: from SZXEML546-MBX.china.huawei.com ([169.254.3.157]) by szxeml420-hub.china.huawei.com ([10.82.67.159]) with mapi id 14.01.0323.003; Thu, 8 Nov 2012 16:43:09 +0800 From: Leaf yeh To: "Bernie Volz (volz)" , "dhcwg@ietf.org" , "tomasz.mrugalski@gmail.com" Thread-Topic: draft-ietf-softwire-map-dhcp-01 Thread-Index: Ac28XcM2fI8tpAwuQc2q5rvEH0/zPwA/HdCw Date: Thu, 8 Nov 2012 08:43:08 +0000 Message-ID: References: <489D13FBFA9B3E41812EA89F188F018E0F55BAD8@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E0F55BAD8@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: "ot@cisco.com" , "congxiao@cernet.edu.cn" , "Wojciech Dec \(wdec\)" Subject: Re: [dhcwg] draft-ietf-softwire-map-dhcp-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, 08 Nov 2012 08:44:20 -0000 Bernie - The OPTION_MAP_DMR should reconsider whether to use the compressed= prefix (same arguments). It should definitely be consistent! This sounds logic to me, rule6-prefix (rule-ipv6-prefix) or rule4-prefix (r= ule-ipv4-prefix) could be, either variable length or fixed length, in the s= ame manner. Supposed Tomek will reply on this point. Bernie - Also, it would be really helpful if, in the cases were suboptions = can exist, these are identified. While I can understand you might want new = ones in the future, that's OK. What options exists today? And, are these re= ally suboptions or encapsulated options? In other words, is this an option = space unique to this option or is this other DHCPv6 options (such as the ot= her options defined in this document). I think we've usually used 'encapsul= ated' to mean the DHCPv6 option space and 'sub-options' to mean a new optio= n space? a. It seems to me Port Parameters option (OPTION_MAP_PORTPARAMS) is not nec= essary to be the sub-option of Rule option (OPTION_MAP_RULE). They might be= in the same level. I believe the parameters of OFFSET, PSID-len and PSID c= ould be independent from the Rule options. The OFFSET have a default value = (=3D 4) defined in section 5.1.3 of draft (MAP), https://datatracker.ietf.o= rg/doc/draft-ietf-softwire-map/?include_text=3D1 . The operator could selec= t the uniform value for all Rules, if it is not 4. The PSID-len and PSID so= unds to design for the non-mapping mechanism, which make the configuration = of CE's port set independently from the mapping Rules. I doubt the FMR, exc= ept for the BMR which is also responsible for the CE's parameter configurat= ion, need the PSID-len and PSID. The OFFSET might deserver a separate optio= n. b. I don't think it is necessary to define sub-options space in the DMR opt= ion (OPTION_MAP_DMR), and even in the Rule option.=20 c. The function of MAP option (OPTION_MAP) sounds only for the grouping of = Rule options. I guess it also can be used for the grouping of Rule options = and Port Parameter option. However, someone may still ask whether it is nec= essary to have a container option for the all the MAP parameters, why not j= ust let it be in the DHCPv6 message. d. The FLAG (E or T) could also be independent from the OPTION_MAP. Suppose= we only except CE in one MAP domain now, and I doubt the CE would like to = select Encapsulation and Translation mode for the different MAP domains in = the future. If necessary, the FLAG (E or T) might deserver a separate optio= n, but it really sounds to me a factory (or manual) setting on the CE. I agree to simplify the nesting structure of the options defined in this dr= aft, then make the understanding & life easier. :-) Best Regards, Leaf -----Original Message----- From: Bernie Volz (volz) [mailto:volz@cisco.com]=20 Sent: Wednesday, November 07, 2012 4:50 AM To: dhcwg@ietf.org Cc: tomasz.mrugalski@gmail.com; ot@cisco.com; congxiao@cernet.edu.cn; Wojci= ech Dec (wdec); Leaf yeh Subject: draft-ietf-softwire-map-dhcp-01 Hi: While I can't really comment much on map, I can suggest that the authors re= visit the formatting of the options. So, here goes ... (Outlook might mess = up the diagrams?) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_MAP_RULE | option-length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | prefix6-len | ea-len | prefix4-len | rule-flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | rule-ipv4-prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | rule-ipv6-prefix | | (variable length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . sub-options (variable length) . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Could this be reworked as: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_MAP_RULE | option-length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | prefix6-length| | +-+-+-+-+-+-+-+-+ rule-ipv6-prefix | | (16 octets) | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ea-len | prefix4-len |rule-ipv4-prfx | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | rule-ipv4-prefix (contd) | rule-flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . sub-options (variable length) . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Keep the prefix-length/prefix together and like it was defined in IAPREFI= X. - Keep the subnet-length/subnet together (you can put the length after if y= ou prefer that, but I don't think we have anything that is a good conventio= n for this). - Use fixed length fields UNLESS compressed format is *really* required or = think the savings is worth it. You could make the rule-ipv6-prefix variable= length (but then why not also the rule-ipv4-prefix)? The OPTION_MAP_DMR should reconsider whether to use the compressed prefix (= same arguments). It should definitely be consistent! Refine OPTION_MAP_PORTPARAMS to: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_MAP_PORTPARAMS | option-length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | offset | PSID-len | PSID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The text can say that offset and PSID-len are restricted to specific ranges= . If you ever need something different, a new option can be added instead o= f using the "reserved bits". Also, it would be really helpful if, in the cases were suboptions can exist= , these are identified. While I can understand you might want new ones in t= he future, that's OK. What options exists today? And, are these really suboptions or encapsulated options? In other words, i= s this an option space unique to this option or is this other DHCPv6 option= s (such as the other options defined in this document). I think we've usual= ly used 'encapsulated' to mean the DHCPv6 option space and 'sub-options' to= mean a new option space? Perhaps the examples will help, but I'm unclear what suboptions go into OPT= ION_MAP vs OPTION_MAP_RULE / OPTION_MAP_DMR? There is some information in S= ection 6, DHCPv6 Server Behavior. Perhaps if I knew MAP well, this would be= obvious? Might be nice to rename section 4.1 from "MAP Option" to "MAP Flags Option"= as that is what it is called in much of text? As Tomasz is working on both this draft and the guidelines drafts, perhaps = some of this would be useful to reflect in the guidelines? Using standard b= uilding blocks (such as prefix-length + prefix (either compressed or not)) = would go a long way to make encoding/decoding structured options easier. Sp= litting these fields, as was proposed in the draft, is just making life for= all much more complicated. And, compressing/variable-length vs fixed lengt= h should also be evaluated carefully. Extracting data from a fixed structur= e is a lot easier and less error prone than from a variable one. Yes, bits = over the wire do matter (especially for low-level functionality such as DHC= P because we'd not like to require fragmentation support), but would a boot= level device really need MAP-T? I am not at the IETF meeting the week and sending it to the list as that we= re it should go anyway. - Bernie From tomasz.mrugalski@gmail.com Thu Nov 8 04:16: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 16AA821F8B71 for ; Thu, 8 Nov 2012 04:16:48 -0800 (PST) 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 9CqEMADF4wmA for ; Thu, 8 Nov 2012 04:16:47 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3888121F85B6 for ; Thu, 8 Nov 2012 04:16:47 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id ro8so2125960pbb.31 for ; Thu, 08 Nov 2012 04:16:47 -0800 (PST) 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:x-enigmail-version:content-type :content-transfer-encoding; bh=FIRP/7MkF+DC0jV2l901+n29LE7kNz41CUyl8BQ2E+k=; b=c1hfW4MDSY/zqR3YMhFEDOI5q/6LzggwQr479ORgQVfuPmJfC7eN0cPqd4GHBlNCdV egiJaTgsn9J8mQ/8Y1oyrGeovj73xX/0emSaJ0qZCSIEPRdfa6oorIv3YEcjFDNITpai 6BRq1dCTru7cKZZhMec3mchWBoQn7+gXMtqzXjc1AqOaH3oqiENIACdaecZtic/bko7B aHj8FHPwgvYaUUOrcFOuacVHaMSzhM+2PvpUrIjLwCf6csPXY9IMmoM3G5J1uwbSNEsq E4Bxiv2PxbcJkacPpxNu4AV/yAYpdgz3+wDHko7Rb9fLxSurVoK42w+5XeMNl/0vqBGZ nsVA== Received: by 10.68.233.230 with SMTP id tz6mr23350807pbc.36.1352377006790; Thu, 08 Nov 2012 04:16:46 -0800 (PST) Received: from dhcp-45c7.meeting.ietf.org ([2001:df8:0:64:cabc:c8ff:fedf:daff]) by mx.google.com with ESMTPS id gq10sm10274051pbc.54.2012.11.08.04.16.44 (version=SSLv3 cipher=OTHER); Thu, 08 Nov 2012 04:16:46 -0800 (PST) Message-ID: <509BA2AB.5050201@gmail.com> Date: Thu, 08 Nov 2012 07:16:43 -0500 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "Bernie Volz (volz)" References: <489D13FBFA9B3E41812EA89F188F018E0F55BAD8@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E0F55BAD8@xmb-rcd-x04.cisco.com> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "dhcwg@ietf.org" , "congxiao@cernet.edu.cn" , "Wojciech Dec \(wdec\)" , "ot@cisco.com" Subject: Re: [dhcwg] draft-ietf-softwire-map-dhcp-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, 08 Nov 2012 12:16:48 -0000 On 12-11-06 15:49, Bernie Volz (volz) wrote: > While I can't really comment much on map, I can suggest that the authors revisit the formatting of the options. The story behind MAP option is that it is a companion document. It delivers whatever is needed by the base MAP spec. That spec used to fluctuate quite a bit, so things were coming and going away. That's why we didn't pay close attention to the option layout. Luckily, MAP spec seems to have stabilized recently, so it's a good time to revisit option formats. Another reason for not doing it so far was time constraint - I have limited bandwidth for IETF activities and decided to focus on v6 failover stuff. Having said that, I agree with almost all your comments and will implement them. > Could this be reworked as: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | OPTION_MAP_RULE | option-length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | prefix6-length| | > +-+-+-+-+-+-+-+-+ rule-ipv6-prefix | > | (16 octets) | > | | > | | > | | > | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | ea-len | prefix4-len |rule-ipv4-prfx | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | rule-ipv4-prefix (contd) | rule-flags | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > . sub-options (variable length) . > . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > - Keep the prefix-length/prefix together and like it was defined in IAPREFIX. > - Keep the subnet-length/subnet together (you can put the length after if you prefer that, but I don't think we have anything that is a good convention for this). > - Use fixed length fields UNLESS compressed format is *really* required or think the savings is worth it. You could make the rule-ipv6-prefix variable length (but then why not also the rule-ipv4-prefix)? Compressed prefix is what Ted suggested. It has its merits, especially if there are many mapping rules. I'll ask about WG preference for fixed vs compressed formats and see how it goes. In general, conditional formatting is something we prefer to avoid. For v4 prefixes the possible savings are minimal - likely 0 or just 1 for /24 prefix. I don't think larger (/16) will ever be reasonably used. Even if they were - that's a saving of mere 2 bytes. So it isn't worth the hassle. In my opinion we have 2 possible choices here: - compressed v6 + fixed v4. - fixed v6 + fixed v4 > The OPTION_MAP_DMR should reconsider whether to use the compressed prefix (same arguments). It should definitely be consistent! Agree. Will update MAP_DMR if the group recommends fixed approach. > Refine OPTION_MAP_PORTPARAMS to: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | OPTION_MAP_PORTPARAMS | option-length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | offset | PSID-len | PSID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > The text can say that offset and PSID-len are restricted to specific ranges. If you ever need something different, a new option can be added instead of using the "reserved bits". Ok, will do that. > Also, it would be really helpful if, in the cases were suboptions can exist, these are identified. While I can understand you might want new ones in the future, that's OK. What options exists today? Currently MAP option can contain MAP_RULE and MAP_DMR options. MAP Rule may also contain MAP_PORTPARAMS. I will clarify the text. But the suboptions is also for future compatibility. Judging from my previous experience with Softwires, there are 15 new drafts around the corner, just waiting to add something new clever and marginally different from what is available today. But your point still stands - I will go over the draft and add lists of allowed suboptions. I think it will also be helpful to write the examples section, perhaps not for each option separately, but rather how all those options are used together. > And, are these really suboptions or encapsulated options? In other words, is this an option space unique to this option or is this other DHCPv6 options (such as the other options defined in this document). I think we've usually used 'encapsulated' to mean the DHCPv6 option space and 'sub-options' to mean a new option space? Excellent point. Bernie, where have you been when requesting suboptions draft was presented? :) > Perhaps the examples will help, but I'm unclear what suboptions go into OPTION_MAP vs OPTION_MAP_RULE / OPTION_MAP_DMR? There is some information in Section 6, DHCPv6 Server Behavior. Perhaps if I knew MAP well, this would be obvious? There used to be a section about it. Do you think putting it back in the draft would help? http://tools.ietf.org/html/draft-mdt-softwire-map-dhcp-option-02#section-4.1 Note that this particular version is outdated, so it would require a refresh. > Might be nice to rename section 4.1 from "MAP Option" to "MAP Flags Option" as that is what it is called in much of text? Agreed. > As Tomasz is working on both this draft and the guidelines drafts, Correction: Tomasz is pretending to be working on both :) I was spending most of my time on v6 failover. Fortunately, the hard part - the design - is now completed. There's still a lot of work to do there and I hope to get many comments on it, but it will likely to be less time consuming from now on. > perhaps some of this would be useful to reflect in the guidelines? Using standard building blocks (such as prefix-length + prefix (either compressed or not)) would go a long way to make encoding/decoding structured options easier. Splitting these fields, as was proposed in the draft, is just making life for all much more complicated. There's a new section planned about prefixes in option guidelines. > And, compressing/variable-length vs fixed length should also be evaluated carefully. Extracting data from a fixed structure is a lot easier and less error prone than from a variable one. Yes, bits over the wire do matter (especially for low-level functionality such as DHCP because we'd not Agree. There's a slide about it with a question about WG preference in the option guidelines presentation that I plan to show today. > like to require fragmentation support), but would a boot level device really need MAP-T? Definitely. Fragmentation is something that is required by 3315 (sort of. It is explicitly mentioned, but without normative language). But I would be surprised if there is a any implementation that is properly prepared for that. > I am not at the IETF meeting the week and sending it to the list as that were it should go anyway. Thanks a lot, Bernie. That's exactly the kind of comments I was hoping to get. Tomek p.s. Sorry for html post, but otherwise the option formats get garbled. From mellon@fugue.com Thu Nov 8 04:51: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 CC89821F8B57 for ; Thu, 8 Nov 2012 04:51:59 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0J+nVH1cdMaM for ; Thu, 8 Nov 2012 04:51:59 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 5693C21F8B50 for ; Thu, 8 Nov 2012 04:51:59 -0800 (PST) Received: from dhcp-47bf.meeting.ietf.org (dhcp-47bf.meeting.ietf.org [130.129.71.191]) by toccata.fugue.com (Postfix) with ESMTPSA id D480F238067D for ; Thu, 8 Nov 2012 07:51:57 -0500 (EST) From: Ted Lemon Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Thu, 8 Nov 2012 07:51:57 -0500 To: "dhcwg@ietf.org WG" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [dhcwg] Final agenda 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, 08 Nov 2012 12:51:59 -0000 Folks, I've uploaded the final agenda for IETF 85. If you think you = are on it, please check. If you are surprised by what you see, please = let me know. :) http://www.ietf.org/proceedings/85/agenda/agenda-85-dhc From Ted.Lemon@nominum.com Thu Nov 8 05:26: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 6259621F8615 for ; Thu, 8 Nov 2012 05:26:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UD+LHf6QGc2R for ; Thu, 8 Nov 2012 05:26:12 -0800 (PST) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by ietfa.amsl.com (Postfix) with ESMTP id C916121F8614 for ; Thu, 8 Nov 2012 05:26:11 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKUJuy8pcBJnz3O5eVyRgqqWTkCxqa4E5O@postini.com; Thu, 08 Nov 2012 05:26:11 PST 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 565471B810E for ; Thu, 8 Nov 2012 05:26:10 -0800 (PST) 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 4AD1A190043 for ; Thu, 8 Nov 2012 05:26:10 -0800 (PST) (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, 8 Nov 2012 05:26:10 -0800 From: Ted Lemon To: " WG" Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-dhcpv4-over-ipv6 Thread-Index: AQHNrTmjFOygSqT8jUKurJPUyMWVCpfglOQA Date: Thu, 8 Nov 2012 13:26:09 +0000 Message-ID: <4E9AA0D4-5135-4464-913E-7B8D0B0737B2@nominum.com> References: <4B380728-0A9D-4B98-85C8-A723667C2676@nominum.com> In-Reply-To: <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: <74C2F7EDEA9BCD4EBC8F64F542C8C350@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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, 08 Nov 2012 13:26:12 -0000 On Oct 18, 2012, at 10:05 AM, Ted Lemon wrote: > The authors have requested a new working group last call on this document= . The document has been updated based on feedback received during the pre= vious working group last call. The authors would appreciate review and fe= edback 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. >=20 > We will evaluate consensus on November 1. There was one response in favor of this WGLC. The document got substantia= l support in the previous WGLC in June. Has that support gone away, or di= d people just not respond because they responded to the previous WGLC? If= you want this document to advance, please do respond to the WGLC. Thanks! From sunqi.thu@gmail.com Thu Nov 8 06:57: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 8C53C21F8590 for ; Thu, 8 Nov 2012 06:57:05 -0800 (PST) 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 zrowLyODlpKz for ; Thu, 8 Nov 2012 06:57:05 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2126021F855E for ; Thu, 8 Nov 2012 06:57:05 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id fb11so2181797pad.31 for ; Thu, 08 Nov 2012 06:57:05 -0800 (PST) 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=+2rLpSMOhTKpC0WomPzrS3V61aloRbr9iPZn04TYWc8=; b=KDk79qnXMqv8HiHJUCh4efOaokRZvwD8rqyglu1kGitqPJ2NF6K5F9qbLlgHOtZgAD iYlme0Ps78mGyysW+XppvBmVPFtoViMPqbnnd1uKxb6ukV8ev54SLdvNj2514ck6HDn2 xeZ2zvXUzNO2btuaxTcl8oNNk98mIKOHBS7oZJqFgYrNjdbK/KjvWJu5qsF2uDoH/mMM iapVf4TsqSo7B0Ej2ewFOMAty5jU9j2kSNEKHmyHe1UAxBtqdYcDstILyaQfcyb6aLpa 7gBKIRYgOqY3SFDi3uCyw/zbvw/EKtONevmVCaWeLELrmlKREiMrjr2v8A4rtQUu1tHC D14A== Received: by 10.68.218.97 with SMTP id pf1mr24585555pbc.96.1352386624965; Thu, 08 Nov 2012 06:57:04 -0800 (PST) Received: from ?IPv6:2001:df8::16:9284:dff:fef3:d346? ([2001:df8:0:16:9284:dff:fef3:d346]) by mx.google.com with ESMTPS id ms11sm16048095pbc.74.2012.11.08.06.57.03 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 08 Nov 2012 06:57:04 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=utf-8 From: Qi Sun In-Reply-To: <4E9AA0D4-5135-4464-913E-7B8D0B0737B2@nominum.com> Date: Thu, 8 Nov 2012 09:57:02 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <513E81E7-CA7D-411D-B143-A0729FDC998B@gmail.com> References: <4B380728-0A9D-4B98-85C8-A723667C2676@nominum.com> <4E9AA0D4-5135-4464-913E-7B8D0B0737B2@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1084) Cc: " WG" 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, 08 Nov 2012 14:57:05 -0000 Dear Ted , I'm in favor of seeing this document moving forward.=20 Thanks! Best Regards! Qi Sun On 2012-11-8, at =E4=B8=8A=E5=8D=888:26, Ted Lemon wrote: > On Oct 18, 2012, at 10:05 AM, Ted Lemon wrote: >> 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. >>=20 >> We will evaluate consensus on November 1. >=20 > There was one response in favor of this WGLC. The document got = substantial support in the previous WGLC in June. Has that support = gone away, or did people just not respond because they responded to the = previous WGLC? If you want this document to advance, please do respond = to the WGLC. >=20 > Thanks! >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From mohamed.boucadair@orange.com Thu Nov 8 07:30: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 D34C121F859A for ; Thu, 8 Nov 2012 07:30:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, 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 8g8mLCtxIC0B for ; Thu, 8 Nov 2012 07:30:25 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 540A421F8596 for ; Thu, 8 Nov 2012 07:30:24 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 7CC21324DCE for ; Thu, 8 Nov 2012 16:30:23 +0100 (CET) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 5D8F735C06A for ; Thu, 8 Nov 2012 16:30:23 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Thu, 8 Nov 2012 16:30:22 +0100 From: To: "" Date: Thu, 8 Nov 2012 16:30:21 +0100 Thread-Topic: IP address vs. FQDN discussion Thread-Index: Ac29xfcgXk0oSmncRrej4Wdd4AHprg== Message-ID: <94C682931C08B048B7A8645303FDC9F36E947B0E73@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: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36E947B0E73PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.11.8.120317 Subject: [dhcwg] IP address vs. FQDN discussion X-BeenThere: dhcwg@ietf.org 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, 08 Nov 2012 15:30:26 -0000 --_000_94C682931C08B048B7A8645303FDC9F36E947B0E73PUEXCB1Bnante_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, As this question is repeatedly raised, including in the ongoing dhc meeting= , we have edited a draft which proposes an approach which conciliates both = modes: It defines a name option encoded as UTF-8 string which can be a doma= in name, IPv4 address literals, etc. The draft is available at: http://tools.ietf.org/html/draft-boucadair-dhc-address-name-encoding-01 Comments are welcome. Cheers, Med --_000_94C682931C08B048B7A8645303FDC9F36E947B0E73PUEXCB1Bnante_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
D= ear all,=20
 
A= s this=20 question is repeatedly raised, including in the ongoing dhc meeting,=20 we=20 have edited a draft which proposes an approach which conciliates both modes= : It=20 defines a name option encoded as UTF-8 string which can be a domain na= me,=20 IPv4 address literals, etc. The draft is availabl= e=20 at:
 
<= A=20 href=3D"http://tools.ietf.org/html/draft-boucadair-dhc-address-name-encodin= g-01">http://tools.ietf.org/html/draft-boucadair-dhc-address-name-encoding-= 01
 
C= omments are=20 welcome.
 
Cheers,
Med
 
--_000_94C682931C08B048B7A8645303FDC9F36E947B0E73PUEXCB1Bnante_-- From Francis.Dupont@fdupont.fr Thu Nov 8 07:38: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 0A98421F89FE for ; Thu, 8 Nov 2012 07:38:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.605 X-Spam-Level: X-Spam-Status: No, score=-0.605 tagged_above=-999 required=5 tests=[AWL=1.994, 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 sNZ9lGxXv3vc for ; Thu, 8 Nov 2012 07:38:11 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id 604E321F851C for ; Thu, 8 Nov 2012 07:38:11 -0800 (PST) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id qA8Fc9rS057585; Thu, 8 Nov 2012 16:38:10 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201211081538.qA8Fc9rS057585@givry.fdupont.fr> From: Francis Dupont To: Ted Lemon In-reply-to: Your message of Thu, 08 Nov 2012 13:26:09 GMT. <4E9AA0D4-5135-4464-913E-7B8D0B0737B2@nominum.com> Date: Thu, 08 Nov 2012 16:38:09 +0100 Sender: Francis.Dupont@fdupont.fr Cc: " WG" 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, 08 Nov 2012 15:38:12 -0000 In your previous mail you wrote: > Has that support gone away, or did > people just not respond because they responded to the previous WGLC? => I am guilty to be in this case... But as I suggested the right solution is to cross post the WGLC in the 6man ML. Regards Francis.Dupont@fdupont.fr (and also fdupont@isc.org) From msiodelski@gmail.com Thu Nov 8 11:41:20 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 CA4CF21F87EE for ; Thu, 8 Nov 2012 11:41:20 -0800 (PST) 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 PPFc-SeMW03z for ; Thu, 8 Nov 2012 11:41:20 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id EF4B921F87E3 for ; Thu, 8 Nov 2012 11:41:19 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so3446879vbb.31 for ; Thu, 08 Nov 2012 11:41:18 -0800 (PST) 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=YQgpBPqnWrSZvvfl7WiCfZTXDL+1Mm7jdYLyT8jYYEw=; b=d9L685Ico2FWqkhGKbhYsZwLGMIJLJHGimhTLPkgbgAxO9QzFPIEEuILoVrik1YNDM /XXYl/z6o8zW+k4ODpEKUW1lAr3dRjiI1rGLIZpomoMuAISSEBa7FbXxhzwyhNt0oFb0 QSvF3a6151jRsw56KTKl392gt8hsJ+0NEKI7QWMN8XefoCC1OlBbuH5z+bWPiyHz1XhB LU21pgAADTGrrJg1bgClKIQlm8Hif2LUwX4waFridTx5LV44WnS1rVoQvqr8xU9pO8q5 AW6M8BtOhtHREyL6oDiUiYEbHccnGaQB//HzH/6dabkOaZxLBmX0ck6makgKY+ktb0jE 1J9w== MIME-Version: 1.0 Received: by 10.59.12.163 with SMTP id er3mr3120572ved.35.1352403678218; Thu, 08 Nov 2012 11:41:18 -0800 (PST) Received: by 10.220.59.136 with HTTP; Thu, 8 Nov 2012 11:41:18 -0800 (PST) In-Reply-To: <5096192D.4020000@gmail.com> References: <5096192D.4020000@gmail.com> Date: Thu, 8 Nov 2012 20:41:18 +0100 Message-ID: From: Marcin Siodelski To: Tomek Mrugalski Content-Type: multipart/alternative; boundary=089e01161354d5487304ce010483 Cc: dhcwg@ietf.org Subject: Re: [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: Thu, 08 Nov 2012 19:41:20 -0000 --089e01161354d5487304ce010483 Content-Type: text/plain; charset=ISO-8859-1 I support this work move forward. Marcin On Sun, Nov 4, 2012 at 8:28 AM, Tomek Mrugalski wrote: > On 12-10-22 17:44, Ted Lemon wrote: > > 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 document and comment on the list. If > > you favor publishing this requirements document, please say so. If > > you oppose publishing it, please also say so. > The DHC meeting (and possibly end of this WGLC) is just a couple days > away. Some time ago over 20 people expressed interest in this work, yet > we have not received a single response to that last call. > > I know that requirement documents may be somewhat boring at times, but > without this document moving forward we can't really do useful work on > the design document (which haven't received any comments neither). > > BTW I support this document and would like it to move forward > (disclaimer: I'm co author). > > Cheers, > Tomek > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > --089e01161354d5487304ce010483 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I support this work move forward.

Marcin

On Sun, Nov 4, 2012 at 8:28 AM, Tomek Mrugalski <tomasz.mrugalski@gmail.com> wrote:
On 12-10-22 17:44, Ted Lem= on wrote:
> The authors have asked for a last call on the DHCPv6 failover
> requirements draft. =A0 This just documents the list of requirements > for a DHCPv6 failover protocol. =A0 If you are interested in DHCPv6 > failover, please review the document and comment on the list. =A0 If > you favor publishing this requirements document, please say so. =A0 If=
> you oppose publishing it, please also say so.
The DHC meeting (and possibly end of this WGLC) is just a couple days=
away. Some time ago over 20 people expressed interest in this work, yet
we have not received a single response to that last call.

I know that requirement documents may be somewhat boring at times, but
without this document moving forward we can't really do useful work on<= br> the design document (which haven't received any comments neither).

BTW I support this document and would like it to move forward
(disclaimer: I'm co author).

Cheers,
Tomek
___________________________________= ____________
dhcwg mailing list
dhcwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dhcwg

--089e01161354d5487304ce010483-- From Stephen.Jacob@nominum.com Thu Nov 8 18:43: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 BAD9211E809A for ; Thu, 8 Nov 2012 18:43:09 -0800 (PST) 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 pKMaBAYbslFJ for ; Thu, 8 Nov 2012 18:43:09 -0800 (PST) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 265B711E8097 for ; Thu, 8 Nov 2012 18:43:09 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKUJxtvBkk9PVrwYUuBc11BteLpb0i1CGS@postini.com; Thu, 08 Nov 2012 18:43:09 PST Received: by shell-too.nominum.com (Postfix, from userid 11053) id 3C904F8002; Thu, 8 Nov 2012 18:43:08 -0800 (PST) Date: Thu, 8 Nov 2012 18:43:08 -0800 From: Stephen Jacob To: Ted Lemon Message-ID: <20121109024308.GA17976@shell-too.nominum.com> Mail-Followup-To: Ted Lemon , " WG" References: <4B380728-0A9D-4B98-85C8-A723667C2676@nominum.com> <4E9AA0D4-5135-4464-913E-7B8D0B0737B2@nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E9AA0D4-5135-4464-913E-7B8D0B0737B2@nominum.com> User-Agent: Mutt/1.4.2.2i X-URI: http://www.nominum.com/ Organization: Nominum, Inc. Cc: " WG" 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: Fri, 09 Nov 2012 02:43:09 -0000 I support advancing this document. Regards, Stephen -- Stephen Jacob | Stephen.Jacob@nominum.com | +1 650 381 6051 Nominum, Inc. | http://www.nominum.com/ | +1 650 381 6000 On Thu, Nov 08, 2012 at 01:26:09PM +0000, Ted Lemon wrote: > On Oct 18, 2012, at 10:05 AM, Ted Lemon wrote: > > 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. > > > > We will evaluate consensus on November 1. > > There was one response in favor of this WGLC. The document got substantial > support in the previous WGLC in June. Has that support gone away, or did > people just not respond because they responded to the previous WGLC? If you > want this document to advance, please do respond to the WGLC. From Mathias.Samuelson@nominum.com Thu Nov 8 19:27: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 0E4C221E803C for ; Thu, 8 Nov 2012 19:27:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.046 X-Spam-Level: X-Spam-Status: No, score=-4.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_IMAGE_ONLY_24=1.552, 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 aedyUn4ZHc78 for ; Thu, 8 Nov 2012 19:27:38 -0800 (PST) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id F32FA21E803A for ; Thu, 8 Nov 2012 19:27:37 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKUJx4KZ/ERK+bEz/zGXjtLmxgxEZoDEqT@postini.com; Thu, 08 Nov 2012 19:27:38 PST 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 9030E1B80B8 for ; Thu, 8 Nov 2012 19:27:36 -0800 (PST) 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 85335190052 for ; Thu, 8 Nov 2012 19:27:36 -0800 (PST) (envelope-from Mathias.Samuelson@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, 8 Nov 2012 19:27:36 -0800 From: Mathias Samuelson To: Ted Lemon Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-dhcpv4-over-ipv6 Thread-Index: AQHNrTmjFOygSqT8jUKurJPUyMWVCpfglOQAgADrF4A= Date: Fri, 9 Nov 2012 03:27:36 +0000 Message-ID: <03A575EB-4646-4492-8B9C-40A9CA15069B@nominum.com> References: <4B380728-0A9D-4B98-85C8-A723667C2676@nominum.com> <4E9AA0D4-5135-4464-913E-7B8D0B0737B2@nominum.com> In-Reply-To: <4E9AA0D4-5135-4464-913E-7B8D0B0737B2@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/related; boundary="_004_03A575EB464644928B9C40A9CA15069Bnominumcom_"; type="multipart/alternative" MIME-Version: 1.0 Cc: " WG" 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: Fri, 09 Nov 2012 03:27:39 -0000 --_004_03A575EB464644928B9C40A9CA15069Bnominumcom_ Content-Type: multipart/alternative; boundary="_000_03A575EB464644928B9C40A9CA15069Bnominumcom_" --_000_03A575EB464644928B9C40A9CA15069Bnominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hey Ted, I support advancing this. Thanks, Mathias On Nov 8, 2012, at 5:26 AM, Ted Lemon > wrote: On Oct 18, 2012, at 10:05 AM, Ted Lemon > wrote: 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. There was one response in favor of this WGLC. The document got substantia= l support in the previous WGLC in June. Has that support gone away, or di= d people just not respond because they responded to the previous WGLC? If= you want this document to advance, please do respond to the WGLC. Thanks! _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg Mathias Samuelson Sr. Product Manager m: +1.650.491.4193 o: +1.650.381.6225 mathias.samuelson@nominum.com [cid:8248574A-055C-4AC6-BBDD-3B293A856454] www.nominum.com What is IDEAL? | Like | Link | Follow --_000_03A575EB464644928B9C40A9CA15069Bnominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <7842AABA817F6046A8915D28D468A9B1@nominum.com> Content-Transfer-Encoding: quoted-printable Hey Ted,

I support advancing this.

Thanks,
Mathias

On Nov 8, 2012, at 5:26 AM, Ted Lemon <Ted.Lemon@nominum.com> wrote:

On Oct 18, 2012, at 10:05 AM, Ted Lemon <ted.lemon@nominum.com> wrote:
The authors have requested a new working group la= st call on this document.   The document has been updated based o= n feedback received during the previous working group last call.  &nbs= p;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 a= nd say why.

We will evaluate consensus on November 1.

There was one response in favor of this WGLC.   The document got = substantial support in the previous WGLC in June.   Has that supp= ort gone away, or did people just not respond because they responded to the= previous WGLC?   If you want this document to advance, please do respond to the WGLC.

Thanks!

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

Mathias Samuelson
Sr. Product Manager
 
m: +1.650.491.4193
o: +1.650.381.6225
mathias.samuelson@nominum.= com



www.nominum.com
What is IDEAL?  |  
Like  |  Link  |  Follow

--_000_03A575EB464644928B9C40A9CA15069Bnominumcom_-- --_004_03A575EB464644928B9C40A9CA15069Bnominumcom_ Content-Type: image/png; name="5835B47C-5F26-40DA-AB76-6EEE8615A3A5[6].png" Content-Description: 5835B47C-5F26-40DA-AB76-6EEE8615A3A5[6].png Content-Disposition: inline; filename="5835B47C-5F26-40DA-AB76-6EEE8615A3A5[6].png"; size=11104; creation-date="Fri, 09 Nov 2012 03:27:36 GMT"; modification-date="Fri, 09 Nov 2012 03:27:36 GMT" Content-ID: <8248574A-055C-4AC6-BBDD-3B293A856454> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAALwAAAAvCAIAAADW2TcRAAAKWmlDQ1BJQ0MgUHJvZmlsZQAASIm1 lgdQFGkWx7/unhxIQ45DzjmD5DigkqOoDDNkGIchCIgKyuIKrAEVETCASlRwVeIaEFFQWQQMGNAF WQTEczEAKirXwIF7dbd1dVV3r+p1/+pfX78v9Peq/gBQmplcbhwsAEA8J4nn7WJPDwwKpuMHAQyo gAhkgR6Tlci18/RcDf4yZh4CaOF9T3uh1l+P+7chyA5PZAEAeaIcxk5kxaN8EeV3LC4vCQC4CuXe zUlclJFUlIV56AJRzl/gyCU+scBhS3xxcYyvtwPKXQAQKEwmLxIA8n1Up6ewItE65A8o63HY0RwA KEooW7OimGyU0QRa8fGbFngfymphf6oT+U81w1ZqMpmRK7y0l8UgOEYncuOYaf/lcfzniI9LXp5D CE0KJ27twr8hoTnOZjq6LzM3znNFD+f4+SwzJ2ytxzJH8Jy9V8Yn2f+JPX2XOT3KYe1KnUSnlTox TDfPZeYle/stc2KKj9P3b30DVtYW7riiR0Q7M5Y5OomxMlfsJveVNQB/YACMgCFwBSApPDVpYcMO m7hpvOjIqCS6HXrTwrXoDA5LR4tuoKdv8D8/5/9nLPTYEr1/tNg7kCjhu5ZWjV7Jo6iY+10LLAOg zhEAsYbvmhLaAzSUW96wknkpSxpm4YFFT5AfCAMJtH8VgRrQRk/SBFgCW+AE3IAH8AVBYANggSgQ D3hgM8gAWSAH5IF94BAoBsfBSVAFzoLzoAlcAtfATXAH9IIH4CkYAqNgEkyBGTAHQRAeokI0SAKS g5QhTcgAMoOsISdoNeQNBUGhUCTEgZKhDGgnlAcVQMVQGVQN/Qy1QNegW1Af9Bgahiagd9BnGIEp sDAsA6vAurAZbAe7w77wejgSToDT4Wx4D1wEl8Nn4Eb4GnwHfgAPwZPwNAIQMiKKyCPaiBnigHgg wUgEwkO2IblIIVKO1CGtSCdyDxlCXiOfMDgMDUPHaGMsMa4YPwwLk4DZhsnHFGOqMI2YDsw9zDBm CvMNS8VKYzWxFlgGNhAbid2MzcEWYiuwDdgb2AfYUewMDocTxaniTHGuuCBcDG4LLh93FFePa8P1 4UZw03g8XgKvibfCe+CZ+CR8Dv4I/gz+Kr4fP4r/SCAT5AgGBGdCMIFD2EEoJNQQrhD6CWOEOaIA UZloQfQgsolpxL3EU8RW4l3iKHGOJEhSJVmRfEkxpCxSEamOdIM0SHpPJpMVyOZkL3I0OZNcRD5H 7iIPkz9RhCgaFAdKCCWZsodSSWmjPKa8p1KpKlRbajA1ibqHWk29Tn1O/chH49PhY/Cx+bbzlfA1 8vXzveEn8ivz2/Fv4E/nL+S/wH+X/7UAUUBFwEGAKbBNoESgRWBAYFqQJqgv6CEYL5gvWCN4S3Bc CC+kIuQkxBbKFjopdF1ohIbQFGkONBZtJ+0U7QZtVBgnrCrMEI4RzhM+K9wjPCUiJGIk4i+SKlIi cllkSBQRVRFliMaJ7hU9L/pQ9LOYjJidWLjYbrE6sX6xWXEpcVvxcPFc8XrxB+KfJegSThKxEvsl miSeSWIkNSS9JDdLHpO8IflaSljKUoollSt1XuqJNCytIe0tvUX6pHS39LSMrIyLDFfmiMx1mdey orK2sjGyB2WvyE7I0eSs5aLlDspdlXtFF6Hb0ePoRfQO+pS8tLyrfLJ8mXyP/JyCqoKfwg6FeoVn iiRFM8UIxYOK7YpTSnJKa5QylGqVnigTlc2Uo5QPK3cqz6qoqgSo7FJpUhlXFVdlqKar1qoOqlHV bNQS1MrV7qvj1M3UY9WPqvdqwBrGGlEaJRp3NWFNE81ozaOafVpYLXMtjla51oA2RdtOO0W7VntY R1Rntc4OnSadN7pKusG6+3U7db/pGevF6Z3Se6ovpO+mv0O/Vf+dgYYBy6DE4L4h1dDZcLths+Fb I02jcKNjRo+MacZrjHcZtxt/NTE14ZnUmUyYKpmGmpaaDpgJm3ma5Zt1mWPN7c23m18y/2RhYpFk cd7iD0tty1jLGsvxVaqrwledWjVipWDFtCqzGrKmW4dan7AespG3YdqU27ywVbRl21bYjtmp28XY nbF7Y69nz7NvsJ91sHDY6tDmiDi6OOY69jgJOfk5FTs9d1ZwjnSudZ5yMXbZ4tLminV1d93vOsCQ YbAY1YwpN1O3rW4d7hR3H/di9xerNVbzVreugde4rTmwZnCt8lrO2iYP4MHwOODxzFPVM8HzFy+c l6dXiddLb33vDO9OH5rPRp8anxlfe9+9vk/91PyS/dr9+f1D/Kv9ZwMcAwoChgJ1A7cG3gmSDIoO ag7GB/sHVwRPr3Nad2jdaIhxSE7Iw/Wq61PX39oguSFuw+WN/BuZGy+EYkMDQmtCvzA9mOXM6TBG WGnYFMuBdZg1ybZlH2RPhFuFF4SPRVhFFESMR1pFHoiciLKJKox6He0QXRz9NsY15njMbKxHbGXs fFxAXH08IT40voUjxInldGyS3ZS6qY+ryc3hDiVYJBxKmOK58yoSocT1ic1JwqiZ6U5WS/4heTjF OqUk5eNm/80XUgVTOandaRppu9PG0p3TT2/BbGFtac+Qz8jKGN5qt7VsG7QtbFv7dsXt2dtHM10y q7JIWbFZv+7Q21Gw48POgJ2t2TLZmdkjP7j8UJvDl8PLGdhluev4j5gfo3/s2W24+8jub7ns3Nt5 enmFeV/yWfm3f9L/qein+T0Re3r2muw9tg+3j7Pv4X6b/VUFggXpBSMH1hxoPEg/mHvww6GNh24V GhUeP0w6nHx4qGh1UfMRpSP7jnwpjip+UGJfUl8qXbq7dPYo+2j/Mdtjdcdljucd/3wi+sSjMpey xnKV8sKTuJMpJ1+e8j/VedrsdHWFZEVexddKTuVQlXdVR7VpdXWNdM3eWrg2uXbiTMiZ3rOOZ5vr tOvK6kXr886Bc8nnXv0c+vPD8+7n2y+YXai7qHyxtIHWkNsINaY1TjVFNQ01BzX3tbi1tLdatjb8 ovNL5SX5SyWXRS7vvUK6kn1l/mr61ek2btvra5HXRto3tj+9Hnj9fodXR88N9xtdN51vXu+067za ZdV16ZbFrZbbZreb7pjcaew27m741fjXhh6Tnsa7pnebe817W/tW9V3pt+m/ds/x3s37jPt3Hqx9 0PfQ7+GjgZCBoUfsR+OP4x6/fZLyZO5p5iB2MPeZwLPC59LPy39T/61+yGTo8rDjcPcLnxdPR1gj k78n/v5lNPsl9WXhmNxY9bjB+KUJ54neV+tejU5yJ+de5/xN8G+lb9TeXPzD9o/uqcCp0be8t/Pv 8t9LvK/8YPShfdpz+vlM/MzcbO5HiY9Vn8w+dX4O+Dw2t/kL/kvRV/Wvrd/cvw3Ox8/Pc5k85qIV QNCEIyJQK10JADUI9Qq9qLXiW/LAiwEt+fZFAn/FSz55MUwAqLAFwD8ToDYCgFI0lTOXbKgnqvva AtjQcCX/EYkRhkvmDCI3odakcH7+PeoJ8eoAfB2Yn59rmp//WoEu9gkAbTNL3nvRx/DQx0kktCar 6/Tkv/invwNLKeWav6IXrwAAIABJREFUeJztfGu0ZVV15jfnXGvvc8591+PWgwKKokAEBeMDCPJS QCKokWDwmRgjMW2bdsS0Go3dbTuSNqPpmI7dI7ZRG0SNr0QFQR4KIiDyKEHeRQEFFMWzqqiqW3Xv OWfvteac/WOfe+sWT+1OepRj1DfOuOPcffZ67L3mmmuu+c25yN3x3HB3Imq+uDszO5DdmBiAZUQB rIYquoq71+GhjfjNozA5gpaAYyKp3QNxdLADBCckAAADAlDTOMEBAwDI8/RmL/YM0AsKTSMru64A yVRYoCouSArPWP/QnRdefMePr7Xp3v4vPviIN/3WyGuPRbtEEZSDAwGAwbNlco4CgAFqqht0BLPy sxd7Ol5AaDBP2QAwuMOT5Ugs5phJ2Da95YJLbrzgYt4+M8ZB1Huq0yUvPvyQo979u3jFS9AqENgr pRBBAPFutdu877xXZH498JxC01yfE5cGZkbkBEdy9JNedd1VX/562vDYuFKZTbJ1Yrufk8aws0VP DYcX/9ZrXvTWM7FkEYQhAJNnIxFXpxDm1Qtgr9D82uD5NI2ZzS1MA33jQF1DCRueuO/8bzz442vb M72hKAXIcg5gJCuKVl+rmr2GbScsevGhrzzrDJx0FIYFkQ3ECAAcrE0rs9IiAHyv3Pwa4JcSml3S o4badlx9wzXnfT3dv2GR+ihR7k63ighAmJHcs3IM6kaldIHNfasmJ150xusOecvpWLpAYcQRTA7x eavTwC7+13/gvfh/x/MJzZw1o6oiAgBbd1z/1e/c9J2Lhqs0wgg5dVJeQFyqknmu00i7oymTOdrF E9rtlbGHcppoBpg8/JCTzn7n2CtfmtwolgTMt25soGWMwXtFZw/H89k0cwZNIzSqOv3I41t+ftc+ ZacFQq4xPoTNW27+5ws2r123QMo2KPerViy0n1Mpvmry5X/0XkiBKoNkU286T44vf9XhPjLchxVg AWCz6oWsWa32Cs2eD1LVpxsuu0vM7jCowoFKwQRLcMKTm2787OefuPbG5dxCSsEpOvfKkFZOHvPZ czA2hCKAGEQghnAmNPJRAKQOJ1hGZFDT7l5PzZ4OZmZ3zzmb2ZygPIfEwIFaKAegE1BGbZVoR+yz 9KgPf3D1ySc+4nUuS2OGlDNV3tbtY2YGZUApWohGRmAnAJDZtclzBhyBoQoY0Qvs//diT0BolEqY 3QC7e2P2PqvcEFAAcIIynDmyA6QZixcd9uH3dyM9fulPl5pUSTtDw1OVYmcfKrAgTeFZiQEABwEo IgBoRpAq9SXGvebwng82m+9fAxGJyHNpGgBwICvAYNQZCoADQJgYfdUHzj7wta/eRGatIqmlbo1e BedBKQccNPcBsmYjd4LCARSxtbtxvBd7KHiwLQLMrDGKG2XzfIWcIHABADdAgLKAAgsXHPbRfzd6 zOFPeSLmUCf0KhCUkQXKgAMKKODmBA+SmwpC0Zvpk3OA7FUzez4GbhgAc+YwETWGzrPc7gwwipAs GxBmB1nV0GojRLTl+I99qHPIyk02E1oRdR/YRUaCADKQAXAowRkMQN3aQx1kH+y892LPxjwmclZK cs6PPvro/Cu7QEg5ORCE3ZQbntEhgTMhBWB4CJMLjv/o+23V5GafARtgASgAAZzMxVwMbAwnVZgC 2PzUtm4vIezVMr8e4IFgOIgIRMnxi7vuOv8fv+mN4eq7pn7zNcRobg4PTAQjEOAOJHdDABMi4eCV p//JH02PtLQQsM8ZNAYo2MAOBiCgwALgnnX3fe4LX6gNhl/BDPZ5HwUykJul72l37F5EZ2/T2Zuf R7X5vBX1aUWe2e6zNuq7fwCb/TxL5c/TGX/Gr3PF/dl+fdb++zM6v3u7tjuBPKjhmU8RCCAa2KqJ 8OBjj37mc/9wwP6rjBCaWwarCQxsjkDMNDuyjZFLBEIEGaAOCQEFl0cdefx73r11qL1YCGSuIGHL CIFp1n7iWXOqMzLyw59c01mw5A9/7y0RYPd5e292QBUiSHUuiqar7mBtrHXHpq0z03W9c2a63S6X TC4aYi4FUBs8lhkxO1hNwVIDU13d/OQmS3m4M7Rs6YKCERjmxgRzA3gQLWQAQ4FNT+2YmtrJFIp2 XLRgoiwoAO7YPtXdtG2HEkngZYsXTJRCrnNS704gUqB5LZGQc2oFAhxOIPQTJPLWHXnr1Pa6rkaG 2qNDrYmRjgA0N3jOIKRsHLgZ3RJwy+CQgexggjmaESEgAKoeZBB1sm2q++TWLSAhCcuWLGkXYEDV ut3upq3bqzq3h4bHx8dHOiECMssbO2AGd1dVhQdiCtK4XNUgjGAGFuRaQyFPbNry1+d85omt2w95 yagC7ogAwIA1G+Sm5NN1wexFyykGGZQo+Yg3no6qahhJdQvgKAxHyhqjNJ3LDgekaI+ML/z+Dy4f HZs4600nAc7uRKQ5SyhyBgeYoSgCXGEKCU2rd6576NJLfrj2/nu37tjpQCyLseGho1/+sjNOf/2S hWOaskjj8mYDjOWa69dcftW1Dz68kZx7M91OqxgdGXrlyw4/7XUnLVu6mAEiIlB2EAGMG9bcdtHl P3pw48b+TK3usZAlSxaf8cbTl04uuuTiS++8a+3OSiGBY1iyaPTolxx25htfPzYynOo6lgUI69Y/ 9KXzv+xciMjkwrF/+76zHe5qLNGcH9+0+fxvfHvDI09s2boNpo60ZOHE4Ye96Mw3/faKpYvrqirL 0oENGx798te+Vim6dVq8cOLP/s3ZrTI68MTmrZ//4rlVVbn7yMjI+//4fROjbQVISIF77n3gO9+7 8KGHN+6c7vZzlqIcHh4+8bhjj/nNo6++8oc33XTTzl5d1UnKztBQ+8jfOOLNbzx1v8ULCZZNhYUI Tzzx5Np711VVdeCBB65fv/7lr3jVxMTE2rVrq6oKjR9fCtk61f37z3/hyc3b2q1h4agYzDMGVImE HFC1UhhAs77YPPFhoBUiHLCMZqM0VKDkJoAmhGAGJpghBjGHE5KCBQa0h0ame/2yNfztf/7uoonh 17z6qIKhqhIKAI2BPjDTiSDBnYxw1U/XfPG887dOzQyPjjBzzjnXuump7d/9weU/v/2OT/75R5Yt HheAXRTYWdnnvnTudTfeKFxWdS7L0oinulW3Tt+79LLrbrzpfX/w+8cc+TIoWBAIyfG9iy49/xvf MokkZYwlGWq3DY9t+Zu//8Lo8HDd7ZtB2q1ur4Ja/fjWB9f/4J77Hvjohz44MdbOAIAadMc96zm2 TNOKpZMUggEQ1I7b7lp3zt/+jx0zlRO3Ox1Th4dt0/2Lf3T1Lbet/fhH/uzglfs4YITkdMsd93DR 2tnr77N8UkN0ZgPU+PY718KZiEaHO0KBgaxgwZpb7z7nb/87h9ivUlm23UM22j5TffeSH1125TU7 d2wnIiKSWPbV+zu6F1z+4zW33v6JD39w9X7LeXbxWLpsstVqbdq06YADDrj77rsffOD+ySNfde+6 datWrQrOUKDKOPdrX7/j7vtC2crmjz+56dvf/7GnfupOV71uYJx22utXLF9SyC7Def5GhwBTFZaB /AgAVKlfxILAqirCc2PvhIsuvvyhRx4t252i0yaOO3t9KUpiqer6/K9+fZ9lSw9ZvT+LqIEZzEjm AJmmGMVUSeJT23Z+7Zvfmprut8fGe71e8FwWITmK2FLihx598vPnfvkTH/nTwDBH7Tjvq9+4+mc3 gAPUA3Fd9dpDneluSg4p2tunu3/3Pz83/omPvfRFq3ICRdx7/4Z/uvAiCiWxMPP09HS73a5rLdtF pbnKLiEKUXemOzwyPFP1U0pla+QXd637x29/54//6F0EqCEbx9YQKIIlxFa/tlhwpUiGfzj3K9um q87QkKlqzpqSE4gpFMNbd/b+91e+/qm/+EhguEOJKbYRy+DsCP0qtWIJIOdcxJYaAxRDmx1uCIIn t+783JfOTVyoGkLR7fcCiznllCQUO3sVxbJTlnXVg3nOqSjbodXZtHXqH750/qc/9fEIMMHhRKSq MzMzQXj58uUxxjU/v3nVqlWtViuAkIALLvnhVdffJOVwv6rLTvvBDY/cc+/9geFWF8wl0XEnntAs 88J4mguu4auJBeaNXJhlZ9YQEljA1JBKTUAwwYBb77zrmutuaA0PVwqXUBSlxNZ0tzs6NLR95/Tn vnjep/7Dx8aHW42I5mwxMAHCMacqxFibX3n1NVt3TIfOUFYfGR97xxlvWLnfihvW3HrRZT8KnQ6H ePe6+5/YtHW/yQVmWHv/w5dd+RNutQGI2vHHH33KKSeHIj644eELLrr4iU1bcq1w+/q3vvPJP/9I 2UIv+bXXX79jpo7tDmm1eHzsPR/8k1ardcVPrr72+p+1y8JNNaXJRQs+8L73jI2P//jaq2+4cY1m tDpDN95885lnnTk51haGmjtCVhCHGIIQG8CC6268dcNjm9sjI3W/Gum0zjzjt1evXnXbnXddeMkP nbhX1Xfee//6Bx968UErCWCJxpKyGYuDRWYnrjmHWCdT9dq8GZWsuO2O27fv7GYJTjLUar3zjLcf uP/+t91220UXX5pASV2CuOV3nvU7hxy8+pY777740h/mXm7FYsOGDevWrT/8kAMbKxBA1np4pAOD Z122z4o1a9Yce8LxGzZsCA7cfc/93/3+9zMFdh4ZW9jtdkkkttvmSiYsrKkeGR4b2DQOEOYHNuwK 9SXCbLxfcg0UFOpqhQQCYO6gnJ0jjS9YOLpgkXKklDjEBK+qenx8fMfUVLtsPbjxsS+e95WPfPB9 Tf0hMICUUggcYqzrzEWxZfvOXqWhhV6v+5Yz3nD6KccRcMiLDrh/wyM33X5Xq9Wa6U2vW3vPfkuP IcZlV1zpYHW45lNPPO59f/gOAoSwesXiAw9Y+alPnzOtXTO68557H9z4yMEHrQiR1t33QHKKxAx6 21m/e+RvHEzAvvu+Y+26u5+ammYiM3vbW848/jdfRsBBB69cv379xo2bQojdOj366KOLxlbTLHES itLqKvUr8oERvPGRx4zI3AF/9dGvPOO0EwC8+OB9731w45pb7+iMjPZ2bL3nnnsOO2ilAeZZzRCL QM4CcsDgZlEo58yhdCFnUkvMMQDr16/vdrtheCxnPfGU4087+dgIHHbQvuvuXnvHfQ8VRXt6evqU 15/yO284mYCDDlq5YcPGNbfe2avr0vWBBx546SEHCnMznmNjY6Ojo8w49NBDh4eHTz31VCOsXr2a p2Z6Xzr3y9O9vpRlcp6eqWIszeAsyuyxMI6xaDfkszXxC7sTAgOJSXmX7iGJFARcIIoENP5DMibE SGpw8NRMt1JH0UFssZRF2Z7u9YuyTE4Sip9df8OVP7nOm9084GYxRFMFEIsiOTZt3kIhuFMpvHBk SADLiYHxsaHhoaFSuGCqel0AteHhRx+mIIWEobI4442vLwltylR3S+Cg5QtPOu64uqpYpHa97+EH ayAZUrZOe9SMU0oLxscahnV0WBZOLMhuVZ1ijJ1OOwAMdATtshWKtrH0+/3pmR0RCICQuWaGw7SM UaBCEGDLli3mDvdUd1dMLmYHOwSYXDRR13VVVQDqqicwcbhmFoiQasp1JW5CCMIFk2rqVVU2pUgx suaaYVW/W8aiHQrr95dMTATAFAJMLl6YsvbrJLFYNLmYAFcrCIsmxnv9OrY73TpVKTcv3FThPtTu DHeGckpjo8PMKMvYKsJIp82XXnrpho0PSyzrrDGWzJxSCiG4O1jAoVfVHAOYGJjjHJ4FMcxRkq5G DnaXxqeH3fIZiFB2OiGWzgIOddakavCGOnUmZzbiSy67vNdPRHAzZjZLEoLmDMAURVGAhGOAeTtG 17oMpA5hVN0ZV4NaYBBQ11XS7O6prhdPLByfGHVLcI8hwo0d+++7X5N0YYTtO3YQoA5VBWBZg0gR uKFXGajrGk6hLMwssBDgpuooy6JKtREzcwiBmyXbIUSWs4hortkBAwFFURARMwURTb1IiGQBsKyt Mg6is83MjAlwFZG67jO8VUYAcIdZt+qVnTYHyXB3r7UOgR1uWVVVU26FMhITEAVmaIxfCGc3VYWj EIbDYSJihhDLfp2ZYGYN/9j0pCGzzc3cCORwPumkk1asWFHXdTOu7h5jNDNVZYa7xiKoqru7D3zE zYyfgzdEVSMxTAAaVw45NekLA7cOUVOQCM1kyjmb5bIs3T2wWPOafNDpE044odWKOVvDaTROHQlB TWNAXdeNAnNYXddRGLBIcM3tstUQ9ckUQFEUMUYAhYRt27bt2DkDjhj4eMgJGzdulBAhYoaRkREA MFhWMg8hMHOqaiEENJYmkRvUmjGwbJFJCJZzWZY5Z1WnWSK/sSVFhOAMC7PEWvM+1c1dgzBgyEpA CNwMBHvzFhlA04FAHFiyqRI7kwsjhKrOFISI1L2xFwii2QNHd2eQqzEAt8gQgrsRUSAGIAS3zI2l ad5sPxulMJ9QmvsrxEJMAIN48cTY773zXUPt0usamkPgXm8GpkUUNnPNZGqp1pSJBuVZZMAnEIwc wgrb5ZSc24f7QK+YD1xVzcATYCkRbKgVSXPu9yJBc90uopsJw3N++RGHn/76kxgIgVXVzDRZs1Y1 ezQRYXJoDjEW7ZaBtHlBQFVVRKSErG5AZJpctDgKmVmv6l92xVUK9BIrx8z02OaZn96wppG/KGHl fvsREBitdpFyD5Y9pxgjA26NslFNdasscs6xkMZXSe4wraveUKtslHR2JHMwkUjTf3DI6qruc6EE YJBoNgCYDR4JxM1jcgw5mxo67eHR0VEiSinNdPtTvaoC+o6p6RmDq6qbFSEURZmSAxCJ6sYc+nXF zAQI8UBSzaAZnoIQA82vsKyWLNVMuy0IzwN2w5EvO/S0U1/nuWpFz6nXaRUsqGZmqu4Mqh5Sn1Tr frdp2NxAMDjHmOEZlGC5iaHatQI1dQ+sZR502kFQdXNM75yqZnZY1dP+jPWnPfXLIP1eNzKn3syK 5ZPve+8fuA2yFLI6i0gMmA3qM8BNoRol9Oqq2+85JEjLHOTEQRAlg4rOEAB1nPa6U3OdACSn7154 2d+f+08bNk9t3Nq7/s4H/urvPvvI5k2h1a66vSMOO/TglSvZwICmPpMxOzPXdW3qzAhAYy2lqheF 6n41NyNbRQhA7vdU1YmNkEFOASwGSIjm5CIcaW4qqzrAUrYArpPXDlUNITTrQlVnCsEIYxPjnc5w qmtm7vbr8771rV/c9/Dt9z/4ze9eWCUtQ7SqOmDfA4ZbUUJMCnNiCeomMdamzY628fC2itiOglxr 1XMH3JtfO0UoojB5qnq/jNCExgP91jPetOXJTdf89AaJhRmWL1t21NGv6ndnNFda9UW10ykxa9PU OcUQ65xCiCnXRQgg2V2/YH5ATuM2n1V9RIQjDj+00+nEdsc4tNrtXlX/4Ac/GBsbq/vVcCt+4Oz3 LhwfKggOd/OiCKpuqiEwM+AuRGUUgVuuhjstollz3CEQglmqzXNVVQYEwksPXfWa44696tqfdjrD AF1x1dVXX/vTUMj2HdOxLGKr7E7vHG4Vv336aUVAYHSnq8AUA3LuC5PEgqUJsLd+tyciTRgAcTAA 4MYGEgIRZ01E1CzU7m45gT3Dk+Y5X6hp4kEgCvf7tQISxQFm9lQFISdnDgYQIQS87uSTvnjueRKC M1+/5uc/u+nGwp2JorBWvXYhrz7qldQ4PqVxhVnONciKMgz4Q4Y66rouJcB8qNV2gkMIaOI2qa6Z uSzav5TQNNTykOC973r7ls2b7lq3LqDcb99lb3/zKTmhFSGA+4BAcMC82cikUphgIYQmypho4KWZ S3wbzELANDuHQfSxOQu97rWvPf1UnuPu7nvo8WuuuiL1e57q97znvYcdsn8YJEMReMBCxSLAHXAi YiDXVa675dDwzM4peAKQDcyAqfa67aGWmxWBm54L8HtvPcs0/eiqn5StYSZRs9zTsizVrbdzauHY 6Hvf+Y4jX3YwGQgY7pS97rSnJCHMdPvZOQOkiJHBklISl16vryQJ0AwJUAoppRhZ4KS54YM858BQ Ms11LMTdGzZGchJSckuzKc/ehNhr8nqGApB6rrnpfCC85vhjbl5z451r74YwS1CwCOdUMaw/033z G954wquPcEcaMEK1W90uwtat21O/Z7N8aqaojpxzzrlb9RWDpHqFmFNKydRn+r+cpmk0Q2QsHBn6 k/e/99P/9TPrNz5SVz0ByojgcIAI2dQgPEsBSuP/rxOySrvVZLwR7fIRY5dtYyLSpD2oughrtlbk Rv001nN/ego5p6o+63ff8rrXvDoCmjMFrquqKNrmECEAWT0yOTkTLVm4YL99V7Q6beQFo502AGKY YXLxohcfsB/EUzUyMTpcENQ8MC1Z2P7QB84+4rAXX3n1tY88+vh0r8vMATIx0nnJUS9/8xtOP2i/ pZ4RAnI2BN5///1jawtCNFBZRAaEUSdfvmSREmcjdgy1SwJiQO1YuGB01f77MDNp6pSDqQhP+y5f 7BzhNrlwXOuaQ8nAskVjK5ctzVy4ptHR4YHjG1i2eMHBB+xbFEWq6oUTY0JgwAwTHfpPH/+zb//T BT+76abHn3pKiHLV7xRh2ZIlrz/llBOPP1YMxBCBOhZPThy47zKJcZ/J8cmJkWZFN8eypZMH7r9C RMR10fhIY6U5Y3LxotX7r1B4ITy5YOKXERqyrMQMNxD33e669/6/POdvVh2w+r984qPtxpWnycVB ApKG+BUYuhU4wnHJV75y2plnYqQDIQicGk0zm54CODIxA6zqMsuPW1YOjUGsHMubb7/zL/7jJ09/ 4xnvP/tdAaBcD9yeZpBgzgqwgxnkqFMdi6KX3Brtl6pWEcDSTO5+LxchkDuxGzQGaRhTN4MRB6kM T27dum3L9qmpqeVLly5YMD7UaRcyIJYdUJAaOaFfo4hQoMUIKRMUQfpVLa1OlR2KVknNxjwI9+p+ EVpm7llbraDauA/QS1ZErrKxWrsMyH0JkpIZly6oEoYiBEhJJUpVJ1Vtl7Gu6yKUaOKWmtEVVMnV 6dEnNk9NTQljqFOsXLFcyMktxGgOEBtQp1TGCKDfr8ooURhgBbo1iNCK6M/0hjpFs7ODxF6VmSVE 6nXrVlkU85wqzxWlQm7uZuQGYSPKoJ/dctvll1z6l5/4WHAgZ4TG929MhTWkvmVyRjbM1F/+5H9e uWT5iX98NkYjIoNFB7Eys+wUG+DmAy2Vsw02mTAzZREHX/mTa6+78aYP/emHO2XjQ8wDk2hWaGh3 dl1VIaIAHEWzAZhdDwfHl5gBBuGstchscJcCzEak7kzMgCscLkxmiYUc7uBsYJYmBsCbRtUDOaCe ExXRjIgD5q3a6lmomRUCQHOWGMwMxE6D1C4CNFdFwyeB1chECJDm/iaw35UarzrRIOwEMFUWMTcQ Gw26ZAoRCAyuIGRVkSK5CjWOnAzzgVMtJ4RYJ2/ER9VDk9pqDiYzNM+i6vKMUNvnFJom1rPRAFmz hJDMN2zYsN8+K8qiWby0MWvNwMyDbEs39Gokv+Dff3zq1rVn/sE7h9/9O+gIuFCS5sHEHG6N0hmc JOKg5o3AAJgbMVeatm2dKmNcMDYxeCU0q6aA5wo1n8+VPvPfWWt8fj1z0T/zftwNu6JJnuXdzcYV PU+Xnr+fsy3uquQ5uvHL1vZcFT6jziZZfnYC7Lo4KPWrtD9bhojMbM6ZS0DBtHLFPkUcDLY57do9 A8Ki6k6MQuB5QVEsTHrtV76587IfoW+oXRxwqDUrCsEHPGZj3oMIrvOfOEocnxgdHx0BDJbmPQw/ zyPNMTvP+u+8f3jXZ94zPttQ8ax/7Omf2d6+QJeev5+zLfLTGvq/ru25KnxGnTxXdveLv/Kz7Fbj XMKKiDSKJ8b4zFTLwakRGUI0oKAsZ85DZWh1Z677X1/FtbcgOzICEBkpqcPBIHIzc7XZOS6DHvPg SxFazkGJax5k0+3Fngyef9DVXB5CIzpPO6JmfjKUNpvHMoYYq15/YWh1Nk9des5n8YvbkRO6FRli iERklomcGTTLgTs85WQOAjWxnGTNYo3ZiJy92KPBcxol5wFNPWC2Zr83vzYADZJYmABmkIyNLgoU QmWLETpbnrrwr/8bfnErGEh9ZEN2YvfGHcPeRBMbEceoCgLIIBB25kyiJv4ra+y9+P+PXavaHIM9 tyTNVy2zkmTEGVpHKBSotTM84soRget6USg6T26+4K/OwS9uhzrcQE6N6akGM7i52tyJjAOiymeN tNn49r3Yw8GNCpnTLk2ewFyq5dPuzv0eLMFqJEVWBFk0OWmO7ECIudtfnnh84+aL/9Nf4+qfIfWR ZpAzUkY21IoMchbAshFBgUSwJlmz4Zkaj+xe7NkI89XJ0w7ynH+diOq67m/f8eTatQslToQOOSDS mppuscApA4FC6OdlrfbmLdMXfvozxz7+9oWveCm6CRJn6np7XRXj44sO2J/GRmPgjIGveeB4gDbb /r0ys+fjhU/3nDs7TVVlZ+/687558z9ftLBbL2m3U2/ncIztfi5sEC4TOKZUtYeHtvR2VC3xspU1 zEh8OE0veOnBJ7/nXcuOfrmLmMwmF8w6K5pcSwZk76FGezx+tSNh0c3oM6645rp//Mb0Aw8tiAgp CTM7cvIQCldjIq/rslP2Uj9J2EHFU8IvPf21L/r9s7DvIgRCDANXamPcEEDmgKJJ8Nibnbun44WP T9tt461ADXR7eOKxW77y1Ycu//G+oSySW53K2CLiul8xc1m2d3ZnyqHhR1K/WrX8xHe/bezEo9Ep UAhEcjaRhqmaM4Eb8WkMmvCs/dmLPQe/otB4k7VssD7qrJdeecV5X9MnnhpDLGtvkcDdmPqBd2TN rc7qE45ZffZbsc9ClBHiYFHQ4FQ953kbpVmvduN43atq9mz8Ugc1zr+oqhK4Rh0tswIPP3n/9y67 8wdXjG6bGao9R+dpAAAAtUlEQVS0HaXLvsHS4pcffuJb385HvQIdQpMo7G5E5mBHYJkj5J7Ro3/Z B9yLf3m8wInl2N1b08QKZbhDAaOcSgT0gdvvWffN7z18y2319PbhfSZf8bYzh09+LcYWIDLIsqcQ Y1OdDVLDjSkMiMBdfflXesa9+BfGC5wjjGcTGocjpyABCmRFiKgzegk33/LoA/ftc/rJmBxFCKgD imIX70wEMyMQc25CLHY/cLqpfC+PsOfj/wBU44Dx023p5AAAAABJRU5ErkJggg== --_004_03A575EB464644928B9C40A9CA15069Bnominumcom_-- From otroan@employees.org Fri Nov 9 06:19: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 D3FD021F85BC for ; Fri, 9 Nov 2012 06:19:46 -0800 (PST) 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=[AWL=-0.000, 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 z3kiGti9qdYT for ; Fri, 9 Nov 2012 06:19:46 -0800 (PST) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 0CD1121F8594 for ; Fri, 9 Nov 2012 06:19:45 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAKwQnVCQ/khR/2dsb2JhbABEw0qBCIIeAQEBAwESASc0CwULC0ZXBjWHYgadKKARkXlhA4ham3mBa4MN X-IronPort-AV: E=McAfee;i="5400,1158,6890"; a="9463065" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-4.cisco.com with ESMTP; 09 Nov 2012 14:19:45 +0000 Received: from dhcp-10-61-102-61.cisco.com (dhcp-10-61-102-61.cisco.com [10.61.102.61]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qA9EJhYl031168 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 9 Nov 2012 14:19:44 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: <4B380728-0A9D-4B98-85C8-A723667C2676@nominum.com> Date: Fri, 9 Nov 2012 09:19:44 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4B380728-0A9D-4B98-85C8-A723667C2676@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1498) Cc: " WG" 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: Fri, 09 Nov 2012 14:19:46 -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 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. >=20 > We will evaluate consensus on November 1. irrespectively of the fact that I think this is a bad idea; this document should await the resolution IPv4 over IPv6 mechanisms in = softwire. depending on the outcome of that, there may or may not be any "users" of = this new DHCPv4 infrastructure. cheers, Ole From Ted.Lemon@nominum.com Fri Nov 9 07:57: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 CC81121F86EF for ; Fri, 9 Nov 2012 07:57:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.449 X-Spam-Level: X-Spam-Status: No, score=-106.449 tagged_above=-999 required=5 tests=[AWL=-0.150, 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 5PvIpNvzTSW0 for ; Fri, 9 Nov 2012 07:57:42 -0800 (PST) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id C7C4E21F86E3 for ; Fri, 9 Nov 2012 07:57:41 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKUJ0n9erqUQzZCdDpB6Rb/lYdB8yB8MPB@postini.com; Fri, 09 Nov 2012 07:57:41 PST 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 060001B8220 for ; Fri, 9 Nov 2012 07:57:41 -0800 (PST) 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 E9EC0190043; Fri, 9 Nov 2012 07:57:40 -0800 (PST) (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, 9 Nov 2012 07:57:41 -0800 From: Ted Lemon To: =?Windows-1252?Q?Ole_Tr=F8an?= Thread-Topic: DHCPv4-over-IPv6 a bad idea? Thread-Index: AQHNvpLypvOqmKsI802XNxNgDTdA+Q== Date: Fri, 9 Nov 2012 15:57:39 +0000 Message-ID: <4295AD8A-EA70-4AC7-9096-6EBC5B79FAAD@nominum.com> References: <4B380728-0A9D-4B98-85C8-A723667C2676@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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: " WG" Subject: [dhcwg] DHCPv4-over-IPv6 a bad idea? X-BeenThere: dhcwg@ietf.org 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, 09 Nov 2012 15:57:42 -0000 On Nov 9, 2012, at 9:19 AM, Ole Tr=F8an wrote: > irrespectively of the fact that I think this is a bad idea; > this document should await the resolution IPv4 over IPv6 mechanisms in so= ftwire. Ole, this document is being used by those documents, but the mechanism is g= eneral, not specific to lw4over6, and has been adopted as a working group w= ork item. So I will note that you do not participate in the working group= consensus to advance this document, but this specific objection isn't a va= lid objection. I would be curious to know what alternate idea you would propose=97do you t= hink that DHCPv6 should configure IPv4 stacks, or do you have some third al= ternative in mind? From otroan@employees.org Fri Nov 9 11:59: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 6549921F86D5 for ; Fri, 9 Nov 2012 11:59:52 -0800 (PST) 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 OGHRbdzt854S for ; Fri, 9 Nov 2012 11:59:51 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 4D40C21F8680 for ; Fri, 9 Nov 2012 11:59:51 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAONfnVCQ/khM/2dsb2JhbABEw0KBCIIeAQEBAwESAWYQC0ZXBjWHYgaeAqAVkX1hA4ham3mBa4MN X-IronPort-AV: E=McAfee;i="5400,1158,6891"; a="146530815" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 09 Nov 2012 19:59:50 +0000 Received: from dhcp-10-61-99-245.cisco.com (dhcp-10-61-99-245.cisco.com [10.61.99.245]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qA9Jxlju001332 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 9 Nov 2012 19:59:49 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: <4295AD8A-EA70-4AC7-9096-6EBC5B79FAAD@nominum.com> Date: Fri, 9 Nov 2012 14:59:48 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <78D640BB-6210-4198-B302-DE61731E6D6E@employees.org> References: <4B380728-0A9D-4B98-85C8-A723667C2676@nominum.com> <4295AD8A-EA70-4AC7-9096-6EBC5B79FAAD@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1498) Cc: " WG" Subject: Re: [dhcwg] DHCPv4-over-IPv6 a bad idea? X-BeenThere: dhcwg@ietf.org 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, 09 Nov 2012 19:59:52 -0000 Ted, >> irrespectively of the fact that I think this is a bad idea; >> this document should await the resolution IPv4 over IPv6 mechanisms = in softwire. >=20 > Ole, this document is being used by those documents, but the mechanism = is general, not specific to lw4over6, and has been adopted as a working = group work item. So I will note that you do not participate in the = working group consensus to advance this document, but this specific = objection isn't a valid objection. >=20 > I would be curious to know what alternate idea you would propose=97do = you think that DHCPv6 should configure IPv4 stacks, or do you have some = third alternative in mind? it is meaningless to have IPv4 configuration information without a = network connection that supports transport of IPv4 packets. use that transport path to run DHCPv4. didn't you volunteer (:-)) to figure out how to run DHCPv4 on an = interface where you have a shared IPv4 address? (as in port 67/68 isn't available). cheers, Ole= From yiu_lee@cable.comcast.com Fri Nov 9 12:05: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 1FDFD21F880C for ; Fri, 9 Nov 2012 12:05:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.02 X-Spam-Level: X-Spam-Status: No, score=-104.02 tagged_above=-999 required=5 tests=[AWL=-0.227, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, MIME_BASE64_BLANKS=0.041, MIME_QP_LONG_LINE=1.396, 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 8XADbZMIGrkv for ; Fri, 9 Nov 2012 12:04:59 -0800 (PST) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id E3C4321F880B for ; Fri, 9 Nov 2012 12:04:57 -0800 (PST) Received: from ([24.40.56.115]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.41259523; Fri, 09 Nov 2012 12:40:11 -0700 Received: from PACDCEXMB05.cable.comcast.com ([169.254.7.131]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%13]) with mapi id 14.02.0318.001; Fri, 9 Nov 2012 15:04:50 -0500 From: "Lee, Yiu" Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-dhcpv4-over-ipv6 Thread-Index: AQHNvrVcz8uHsslVjkGzeMsL+Wnaxw== Date: Fri, 9 Nov 2012 20:04:49 +0000 Message-ID: In-Reply-To: <03A575EB-4646-4492-8B9C-40A9CA15069B@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [24.40.55.70] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3435318289_1192483" MIME-Version: 1.0 To: Mathias Samuelson , Ted Lemon Cc: " WG" 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: Fri, 09 Nov 2012 20:05:00 -0000 --B_3435318289_1192483 Content-type: multipart/mixed; boundary="B_3435318288_1212979" --B_3435318288_1212979 Content-type: multipart/alternative; boundary="B_3435318288_1159501" --B_3435318288_1159501 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit I also support to move forward. Thanks, Yiu From: Mathias Samuelson Date: Thursday, November 8, 2012 10:27 PM To: Ted Lemon Cc: " WG" Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv4-over-ipv6 Hey Ted, I support advancing this. Thanks, Mathias On Nov 8, 2012, at 5:26 AM, Ted Lemon wrote: > On Oct 18, 2012, at 10:05 AM, Ted Lemon wrote: >> 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. >> >> We will evaluate consensus on November 1. > > There was one response in favor of this WGLC. The document got substantial > support in the previous WGLC in June. Has that support gone away, or did > people just not respond because they responded to the previous WGLC? If you > want this document to advance, please do respond to the WGLC. > > Thanks! > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg Mathias Samuelson Sr. Product Manager m: +1.650.491.4193 o: +1.650.381.6225 mathias.samuelson@nominum.com www.nominum.com What is IDEAL? | Like | Link | Follow --B_3435318288_1159501 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
I also support to move forwa= rd.

Thanks,
Yiu

From: Mathias Samuelson <Mathias.Samuelson@nominum.com>
Date: Thursday, November 8, 2012 10:27 PM<= br>To: Ted Lemon <Ted.Lemon@nominum.com>
Cc: "<dhcwg@ietf.org> WG" <dhcwg@ietf.org>
Subject: Re: [dhcwg] WGLC: draft-ietf-dh= c-dhcpv4-over-ipv6

Hey Ted,

I support advancing this.

Than= ks,
Mathias

On Nov 8, 2012, at = 5:26 AM, Ted Lemon <Ted.Lemon@nomi= num.com> wrote:

On Oct 18, 2012, at 10:05 AM, Ted Lemon <ted.lemon@nominum.com> wrote:
The authors have requested a new working group last call on this do= cument.   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 an= d say why.

We will evaluate consensus on November 1.

There was one response in favor of this WGLC.   The document got = substantial support in the previous WGLC in June.   Has that suppo= rt gone away, or did people just not respond because they responded to the p= revious WGLC?   If you want this document to advance, please do respond to the WGLC.

Thanks!

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

Mathias Samuelson
Sr. Product Manager
 
m: +1.650.491.4193
o: +1.650.381.6225
mathia= s.samuelson@nominum.com

<= span>

www.nominum.com
What is IDEAL?  |  
Like  |  Link  |  Follow

--B_3435318288_1159501-- --B_3435318288_1212979 Content-type: image/png; name="5835B47C-5F26-40DA-AB76-6EEE8615A3A5[6].png"; x-mac-type="504E4766" Content-ID: <8248574A-055C-4AC6-BBDD-3B293A856454> Content-disposition: attachment; filename="5835B47C-5F26-40DA-AB76-6EEE8615A3A5[6].png" Content-transfer-encoding: base64 iVBORw0KGgoAAAANSUhEUgAAALwAAAAvCAIAAADW2TcRAAAKWmlDQ1BJQ0MgUHJvZmlsZQAA SIm1lgdQFGkWx7/unhxIQ45DzjmD5DigkqOoDDNkGIchCIgKyuIKrAEVETCASlRwVeIaEFFQ WQQMGNAFWQTEczEAKirXwIF7dbd1dVV3r+p1/+pfX78v9Peq/gBQmplcbhwsAEA8J4nn7WJP DwwKpuMHAQyogAhkgR6Tlci18/RcDf4yZh4CaOF9T3uh1l+P+7chyA5PZAEAeaIcxk5kxaN8 EeV3LC4vCQC4CuXezUlclJFUlIV56AJRzl/gyCU+scBhS3xxcYyvtwPKXQAQKEwmLxIA8n1U p6ewItE65A8o63HY0RwAKEooW7OimGyU0QRa8fGbFngfymphf6oT+U81w1ZqMpmRK7y0l8Ug OEYncuOYaf/lcfzniI9LXp5DCE0KJ27twr8hoTnOZjq6LzM3znNFD+f4+SwzJ2ytxzJH8Jy9 V8Yn2f+JPX2XOT3KYe1KnUSnlToxTDfPZeYle/stc2KKj9P3b30DVtYW7riiR0Q7M5Y5Oomx MlfsJveVNQB/YACMgCFwBSApPDVpYcMOm7hpvOjIqCS6HXrTwrXoDA5LR4tuoKdv8D8/5/9n LPTYEr1/tNg7kCjhu5ZWjV7Jo6iY+10LLAOgzhEAsYbvmhLaAzSUW96wknkpSxpm4YFFT5Af CAMJtH8VgRrQRk/SBFgCW+AE3IAH8AVBYANggSgQD3hgM8gAWSAH5IF94BAoBsfBSVAFzoLz oAlcAtfATXAH9IIH4CkYAqNgEkyBGTAHQRAeokI0SAKSg5QhTcgAMoOsISdoNeQNBUGhUCTE gZKhDGgnlAcVQMVQGVQN/Qy1QNegW1Af9Bgahiagd9BnGIEpsDAsA6vAurAZbAe7w77wejgS ToDT4Wx4D1wEl8Nn4Eb4GnwHfgAPwZPwNAIQMiKKyCPaiBnigHggwUgEwkO2IblIIVKO1CGt SCdyDxlCXiOfMDgMDUPHaGMsMa4YPwwLk4DZhsnHFGOqMI2YDsw9zDBmCvMNS8VKYzWxFlgG NhAbid2MzcEWYiuwDdgb2AfYUewMDocTxaniTHGuuCBcDG4LLh93FFePa8P14UZw03g8XgKv ibfCe+CZ+CR8Dv4I/gz+Kr4fP4r/SCAT5AgGBGdCMIFD2EEoJNQQrhD6CWOEOaIAUZloQfQg solpxL3EU8RW4l3iKHGOJEhSJVmRfEkxpCxSEamOdIM0SHpPJpMVyOZkL3I0OZNcRD5H7iIP kz9RhCgaFAdKCCWZsodSSWmjPKa8p1KpKlRbajA1ibqHWk29Tn1O/chH49PhY/Cx+bbzlfA1 8vXzveEn8ivz2/Fv4E/nL+S/wH+X/7UAUUBFwEGAKbBNoESgRWBAYFqQJqgv6CEYL5gvWCN4 S3BcCC+kIuQkxBbKFjopdF1ohIbQFGkONBZtJ+0U7QZtVBgnrCrMEI4RzhM+K9wjPCUiJGIk 4i+SKlIicllkSBQRVRFliMaJ7hU9L/pQ9LOYjJidWLjYbrE6sX6xWXEpcVvxcPFc8XrxB+Kf JegSThKxEvslmiSeSWIkNSS9JDdLHpO8IflaSljKUoollSt1XuqJNCytIe0tvUX6pHS39LSM rIyLDFfmiMx1mdeyorK2sjGyB2WvyE7I0eSs5aLlDspdlXtFF6Hb0ePoRfQO+pS8tLyrfLJ8 mXyP/JyCqoKfwg6FeoVniiRFM8UIxYOK7YpTSnJKa5QylGqVnigTlc2Uo5QPK3cqz6qoqgSo 7FJpUhlXFVdlqKar1qoOqlHVbNQS1MrV7qvj1M3UY9WPqvdqwBrGGlEaJRp3NWFNE81ozaOa fVpYLXMtjla51oA2RdtOO0W7VntYR1Rntc4OnSadN7pKusG6+3U7db/pGevF6Z3Se6ovpO+m v0O/Vf+dgYYBy6DE4L4h1dDZcLths+FbI02jcKNjRo+MacZrjHcZtxt/NTE14ZnUmUyYKpmG mpaaDpgJm3ma5Zt1mWPN7c23m18y/2RhYpFkcd7iD0tty1jLGsvxVaqrwledWjVipWDFtCqz GrKmW4dan7AespG3YdqU27ywVbRl21bYjtmp28XYnbF7Y69nz7NvsJ91sHDY6tDmiDi6OOY6 9jgJOfk5FTs9d1ZwjnSudZ5yMXbZ4tLminV1d93vOsCQYbAY1YwpN1O3rW4d7hR3H/di9xer NVbzVreugde4rTmwZnCt8lrO2iYP4MHwOODxzFPVM8HzFy+cl6dXiddLb33vDO9OH5rPRp8a nxlfe9+9vk/91PyS/dr9+f1D/Kv9ZwMcAwoChgJ1A7cG3gmSDIoOag7GB/sHVwRPr3Nad2jd aIhxSE7Iw/Wq61PX39oguSFuw+WN/BuZGy+EYkMDQmtCvzA9mOXM6TBGWGnYFMuBdZg1ybZl H2RPhFuFF4SPRVhFFESMR1pFHoiciLKJKox6He0QXRz9NsY15njMbKxHbGXsfFxAXH08IT40 voUjxInldGyS3ZS6qY+ryc3hDiVYJBxKmOK58yoSocT1ic1JwqiZ6U5WS/4heTjFOqUk5eNm /80XUgVTOandaRppu9PG0p3TT2/BbGFtac+Qz8jKGN5qt7VsG7QtbFv7dsXt2dtHM10yq7JI WbFZv+7Q21Gw48POgJ2t2TLZmdkjP7j8UJvDl8PLGdhluev4j5gfo3/s2W24+8jub7ns3Nt5 enmFeV/yWfm3f9L/qein+T0Re3r2muw9tg+3j7Pv4X6b/VUFggXpBSMH1hxoPEg/mHvww6GN h24VGhUeP0w6nHx4qGh1UfMRpSP7jnwpjip+UGJfUl8qXbq7dPYo+2j/Mdtjdcdljucd/3wi +sSjMpeyxnKV8sKTuJMpJ1+e8j/VedrsdHWFZEVexddKTuVQlXdVR7VpdXWNdM3eWrg2uXbi TMiZ3rOOZ5vrtOvK6kXr886Bc8nnXv0c+vPD8+7n2y+YXai7qHyxtIHWkNsINaY1TjVFNQ01 BzX3tbi1tLdatjb8ovNL5SX5SyWXRS7vvUK6kn1l/mr61ek2btvra5HXRto3tj+9Hnj9fodX R88N9xtdN51vXu+067zaZdV16ZbFrZbbZreb7pjcaew27m741fjXhh6Tnsa7pnebe817W/tW 9V3pt+m/ds/x3s37jPt3Hqx90PfQ7+GjgZCBoUfsR+OP4x6/fZLyZO5p5iB2MPeZwLPC59LP y39T/61+yGTo8rDjcPcLnxdPR1gjk78n/v5lNPsl9WXhmNxY9bjB+KUJ54neV+tejU5yJ+de 5/xN8G+lb9TeXPzD9o/uqcCp0be8t/Pv8t9LvK/8YPShfdpz+vlM/MzcbO5HiY9Vn8w+dX4O +Dw2t/kL/kvRV/Wvrd/cvw3Ox8/Pc5k85qIVQNCEIyJQK10JADUI9Qq9qLXiW/LAiwEt+fZF An/FSz55MUwAqLAFwD8ToDYCgFI0lTOXbKgnqvvaAtjQcCX/EYkRhkvmDCI3odakcH7+PeoJ 8eoAfB2Yn59rmp//WoEu9gkAbTNL3nvRx/DQx0kktCar6/Tkv/invwNLKeWav6IXrwAAIABJ REFUeJztfGu0ZVV15jfnXGvvc8591+PWgwKKokAEBeMDCPJSQCKokWDwmRgjMW2bdsS0Go3d bTuSNqPpmI7dI7ZRG0SNr0QFQR4KIiDyKEHeRQEFFMWzqqiqW3XvOWfvteac/WOfe+sWT+1O epRj1DfOuOPcffZ67L3mmmuu+c25yN3x3HB3Imq+uDszO5DdmBiAZUQBrIYquoq71+GhjfjN ozA5gpaAYyKp3QNxdLADBCckAAADAlDTOMEBAwDI8/RmL/YM0AsKTSMru64AyVRYoCouSArP WP/QnRdefMePr7Xp3v4vPviIN/3WyGuPRbtEEZSDAwGAwbNlco4CgAFqqht0BLPysxd7Ol5A aDBP2QAwuMOT5Ugs5phJ2Da95YJLbrzgYt4+M8ZB1Huq0yUvPvyQo979u3jFS9AqENgrpRBB APFutdu877xXZH498JxC01yfE5cGZkbkBEdy9JNedd1VX/562vDYuFKZTbJ1Yrufk8aws0VP DYcX/9ZrXvTWM7FkEYQhAJNnIxFXpxDm1Qtgr9D82uD5NI2ZzS1MA33jQF1DCRueuO/8bzz4 42vbM72hKAXIcg5gJCuKVl+rmr2GbScsevGhrzzrDJx0FIYFkQ3ECAAcrE0rs9IiAHyv3Pwa 4JcSml3So4badlx9wzXnfT3dv2GR+ihR7k63ighAmJHcs3IM6kaldIHNfasmJ150xusOecvp WLpAYcQRTA7xeavTwC7+13/gvfh/x/MJzZw1o6oiAgBbd1z/1e/c9J2Lhqs0wgg5dVJeQFyq knmu00i7oymTOdrFE9rtlbGHcppoBpg8/JCTzn7n2CtfmtwolgTMt25soGWMwXtFZw/H89k0 cwZNIzSqOv3I41t+ftc+ZacFQq4xPoTNW27+5ws2r123QMo2KPerViy0n1Mpvmry5X/0XkiB KoNkU286T44vf9XhPjLchxVgAWCz6oWsWa32Cs2eD1LVpxsuu0vM7jCowoFKwQRLcMKTm278 7OefuPbG5dxCSsEpOvfKkFZOHvPZczA2hCKAGEQghnAmNPJRAKQOJ1hGZFDT7l5PzZ4OZmZ3 zzmb2ZygPIfEwIFaKAegE1BGbZVoR+yz9KgPf3D1ySc+4nUuS2OGlDNV3tbtY2YGZUApWohG RmAnAJDZtclzBhyBoQoY0Qvs//diT0BolEqY3QC7e2P2PqvcEFAAcIIynDmyA6QZixcd9uH3 dyM9fulPl5pUSTtDw1OVYmcfKrAgTeFZiQEABwEoIgBoRpAq9SXGvebwng82m+9fAxGJyHNp GgBwICvAYNQZCoADQJgYfdUHzj7wta/eRGatIqmlbo1eBedBKQccNPcBsmYjd4LCARSxtbtx vBd7KHiwLQLMrDGKG2XzfIWcIHABADdAgLKAAgsXHPbRfzd6zOFPeSLmUCf0KhCUkQXKgAMK KODmBA+SmwpC0Zvpk3OA7FUzez4GbhgAc+YwETWGzrPc7gwwipAsGxBmB1nV0GojRLTl+I99 qHPIyk02E1oRdR/YRUaCADKQAXAowRkMQN3aQx1kH+y892LPxjwmclZKcs6PPvro/Cu7QEg5 ORCE3ZQbntEhgTMhBWB4CJMLjv/o+23V5GafARtgASgAAZzMxVwMbAwnVZgC2PzUtm4vIezV Mr8e4IFgOIgIRMnxi7vuOv8fv+mN4eq7pn7zNcRobg4PTAQjEOAOJHdDABMi4eCVp//JH02P tLQQsM8ZNAYo2MAOBiCgwALgnnX3fe4LX6gNhl/BDPZ5HwUykJul72l37F5EZ2/T2ZufR7X5 vBX1aUWe2e6zNuq7fwCb/TxL5c/TGX/Gr3PF/dl+fdb++zM6v3u7tjuBPKjhmU8RCCAa2KqJ 8OBjj37mc/9wwP6rjBCaWwarCQxsjkDMNDuyjZFLBEIEGaAOCQEFl0cdefx73r11qL1YCGSu IGHLCIFp1n7iWXOqMzLyw59c01mw5A9/7y0RYPd5e292QBUiSHUuiqar7mBtrHXHpq0z03W9 c2a63S6XTC4aYi4FUBs8lhkxO1hNwVIDU13d/OQmS3m4M7Rs6YKCERjmxgRzA3gQLWQAQ4FN T+2YmtrJFIp2XLRgoiwoAO7YPtXdtG2HEkngZYsXTJRCrnNS704gUqB5LZGQc2oFAhxOIPQT JPLWHXnr1Pa6rkaG2qNDrYmRjgA0N3jOIKRsHLgZ3RJwy+CQgexggjmaESEgAKoeZBB1sm2q ++TWLSAhCcuWLGkXYEDVut3upq3bqzq3h4bHx8dHOiECMssbO2AGd1dVhQdiCtK4XNUgjGAG FuRaQyFPbNry1+d85omt2w95yagC7ogAwIA1G+Sm5NN1wexFyykGGZQo+Yg3no6qahhJdQvg KAxHyhqjNJ3LDgekaI+ML/z+Dy4fHZs4600nAc7uRKQ5SyhyBgeYoSgCXGEKCU2rd6576NJL frj2/nu37tjpQCyLseGho1/+sjNOf/2ShWOaskjj8mYDjOWa69dcftW1Dz68kZx7M91Oqxgd GXrlyw4/7XUnLVu6mAEiIlB2EAGMG9bcdtHlP3pw48b+TK3usZAlSxaf8cbTl04uuuTiS++8 a+3OSiGBY1iyaPTolxx25htfPzYynOo6lgUI69Y/9KXzv+xciMjkwrF/+76zHe5qLNGcH9+0 +fxvfHvDI09s2boNpo60ZOHE4Ye96Mw3/faKpYvrqirL0oENGx798te+Vim6dVq8cOLP/s3Z rTI68MTmrZ//4rlVVbn7yMjI+//4fROjbQVISIF77n3gO9+78KGHN+6c7vZzlqIcHh4+8bhj j/nNo6++8oc33XTTzl5d1UnKztBQ+8jfOOLNbzx1v8ULCZZNhYUITzzx5Np711VVdeCBB65f v/7lr3jVxMTE2rVrq6oKjR9fCtk61f37z3/hyc3b2q1h4agYzDMGVImEHFC1UhhAs77YPPFh oBUiHLCMZqM0VKDkJoAmhGAGJpghBjGHE5KCBQa0h0ame/2yNfztf/7uoonh17z6qIKhqhIK AI2BPjDTiSDBnYxw1U/XfPG887dOzQyPjjBzzjnXuump7d/9weU/v/2OT/75R5YtHheAXRTY WdnnvnTudTfeKFxWdS7L0oinulW3Tt+79LLrbrzpfX/w+8cc+TIoWBAIyfG9iy49/xvfMokk ZYwlGWq3DY9t+Zu//8Lo8HDd7ZtB2q1ur4Ja/fjWB9f/4J77Hvjohz44MdbOAIAadMc96zm2 TNOKpZMUggEQ1I7b7lp3zt/+jx0zlRO3Ox1Th4dt0/2Lf3T1Lbet/fhH/uzglfs4YITkdMsd 93DR2tnr77N8UkN0ZgPU+PY718KZiEaHO0KBgaxgwZpb7z7nb/87h9ivUlm23UM22j5TffeS H1125TU7d2wnIiKSWPbV+zu6F1z+4zW33v6JD39w9X7LeXbxWLpsstVqbdq06YADDrj77rsf fOD+ySNfde+6datWrQrOUKDKOPdrX7/j7vtC2crmjz+56dvf/7GnfupOV71uYJx22utXLF9S yC7Def5GhwBTFZaB/AgAVKlfxILAqirCc2PvhIsuvvyhRx4t252i0yaOO3t9KUpiqer6/K9+ fZ9lSw9ZvT+LqIEZzEjmAJmmGMVUSeJT23Z+7Zvfmprut8fGe71e8FwWITmK2FLihx598vPn fvkTH/nTwDBH7Tjvq9+4+mc3gAPUA3Fd9dpDneluSg4p2tunu3/3Pz83/omPvfRFq3ICRdx7 /4Z/uvAiCiWxMPP09HS73a5rLdtFpbnKLiEKUXemOzwyPFP1U0pla+QXd637x29/54//6F0E qCEbx9YQKIIlxFa/tlhwpUiGfzj3K9umq87QkKlqzpqSE4gpFMNbd/b+91e+/qm/+EhguEOJ KbYRy+DsCP0qtWIJIOdcxJYaAxRDmx1uCIInt+783JfOTVyoGkLR7fcCiznllCQUO3sVxbJT lnXVg3nOqSjbodXZtHXqH750/qc/9fEIMMHhRKSqMzMzQXj58uUxxjU/v3nVqlWtViuAkIAL LvnhVdffJOVwv6rLTvvBDY/cc+/9geFWF8wl0XEnntAs88J4mguu4auJBeaNXJhlZ9YQEljA 1JBKTUAwwYBb77zrmutuaA0PVwqXUBSlxNZ0tzs6NLR95/Tnvnjep/7Dx8aHW42I5mwxMAHC MacqxFibX3n1NVt3TIfOUFYfGR97xxlvWLnfihvW3HrRZT8KnQ6HePe6+5/YtHW/yQVmWHv/ w5dd+RNutQGI2vHHH33KKSeHIj644eELLrr4iU1bcq1w+/q3vvPJP/9I2UIv+bXXX79jpo7t Dmm1eHzsPR/8k1ardcVPrr72+p+1y8JNNaXJRQs+8L73jI2P//jaq2+4cY1mtDpDN95885ln nTk51haGmjtCVhCHGIIQG8CC6268dcNjm9sjI3W/Gum0zjzjt1evXnXbnXddeMkPnbhX1Xfe e//6Bx968UErCWCJxpKyGYuDRWYnrjmHWCdT9dq8GZWsuO2O27fv7GYJTjLUar3zjLcfuP/+ t91220UXX5pASV2CuOV3nvU7hxy8+pY777740h/mXm7FYsOGDevWrT/8kAMbKxBA1np4pAOD Z122z4o1a9Yce8LxGzZsCA7cfc/93/3+9zMFdh4ZW9jtdkkkttvmSiYsrKkeGR4b2DQOEOYH NuwK9SXCbLxfcg0UFOpqhQQCYO6gnJ0jjS9YOLpgkXKklDjEBK+qenx8fMfUVLtsPbjxsS+e 95WPfPB9Tf0hMICUUggcYqzrzEWxZfvOXqWhhV6v+5Yz3nD6KccRcMiLDrh/wyM33X5Xq9Wa 6U2vW3vPfkuPIcZlV1zpYHW45lNPPO59f/gOAoSwesXiAw9Y+alPnzOtXTO68557H9z4yMEH rQiR1t33QHKKxAx621m/e+RvHEzAvvu+Y+26u5+ammYiM3vbW848/jdfRsBBB69cv379xo2b QojdOj366KOLxlbTLHESitLqKvUr8oERvPGRx4zI3AF/9dGvPOO0EwC8+OB9731w45pb7+iM jPZ2bL3nnnsOO2ilAeZZzRCLQM4CcsDgZlEo58yhdCFnUkvMMQDr16/vdrtheCxnPfGU4087 +dgIHHbQvuvuXnvHfQ8VRXt6evqU15/yO284mYCDDlq5YcPGNbfe2avr0vWBBx546SEHCnMz nmNjY6Ojo8w49NBDh4eHTz31VCOsXr2ap2Z6Xzr3y9O9vpRlcp6eqWIszeAsyuyxMI6xaDfk szXxC7sTAgOJSXmX7iGJFARcIIoENP5DMibESGpw8NRMt1JH0UFssZRF2Z7u9YuyTE4Sip9d f8OVP7nOm9084GYxRFMFEIsiOTZt3kIhuFMpvHBkSADLiYHxsaHhoaFSuGCqel0AteHhRx+m IIWEobI4442vLwltylR3S+Cg5QtPOu64uqpYpHa97+EHayAZUrZOe9SMU0oLxscahnV0WBZO LMhuVZ1ijJ1OOwAMdATtshWKtrH0+/3pmR0RCICQuWaGw7SMUaBCEGDLli3mDvdUd1dMLmYH OwSYXDRR13VVVQDqqicwcbhmFoiQasp1JW5CCMIFk2rqVVU2pUgxsuaaYVW/W8aiHQrr95dM TATAFAJMLl6YsvbrJLFYNLmYAFcrCIsmxnv9OrY73TpVKTcv3FThPtTuDHeGckpjo8PMKMvY KsJIp82XXnrpho0PSyzrrDGWzJxSCiG4O1jAoVfVHAOYGJjjHJ4FMcxRkq5GDnaXxqeH3fIZ iFB2OiGWzgIOddakavCGOnUmZzbiSy67vNdPRHAzZjZLEoLmDMAURVGAhGOAeTtG17oMpA5h VN0ZV4NaYBBQ11XS7O6prhdPLByfGHVLcI8hwo0d+++7X5N0YYTtO3YQoA5VBWBZg0gRuKFX GajrGk6hLMwssBDgpuooy6JKtREzcwiBmyXbIUSWs4hortkBAwFFURARMwURTb1IiGQBsKyt Mg6is83MjAlwFZG67jO8VUYAcIdZt+qVnTYHyXB3r7UOgR1uWVVVU26FMhITEAVmaIxfCGc3 VYWjEIbDYSJihhDLfp2ZYGYN/9j0pCGzzc3cCORwPumkk1asWFHXdTOu7h5jNDNVZYa7xiKo qru7D3zEzYyfgzdEVSMxTAAaVw45NekLA7cOUVOQCM1kyjmb5bIs3T2wWPOafNDpE044odWK OVvDaTROHQlBTWNAXdeNAnNYXddRGLBIcM3tstUQ9ckUQFEUMUYAhYRt27bt2DkDjhj4eMgJ GzdulBAhYoaRkREAMFhWMg8hMHOqaiEENJYmkRvUmjGwbJFJCJZzWZY5Z1WnWSK/sSVFhOAM C7PEWvM+1c1dgzBgyEpACNwMBHvzFhlA04FAHFiyqRI7kwsjhKrOFISI1L2xFwii2QNHd2eQ qzEAt8gQgrsRUSAGIAS3zI2lad5sPxulMJ9QmvsrxEJMAIN48cTY773zXUPt0usamkPgXm8G pkUUNnPNZGqp1pSJBuVZZMAnEIwcwgrb5ZSc24f7QK+YD1xVzcATYCkRbKgVSXPu9yJBc90u opsJw3N++RGHn/76kxgIgVXVzDRZs1Y1ezQRYXJoDjEW7ZaBtHlBQFVVRKSErG5AZJpctDgK mVmv6l92xVUK9BIrx8z02OaZn96wppG/KGHlfvsREBitdpFyD5Y9pxgjA26NslFNdasscs6x kMZXSe4wraveUKtslHR2JHMwkUjTf3DI6qruc6EEYJBoNgCYDR4JxM1jcgw5mxo67eHR0VEi SinNdPtTvaoC+o6p6RmDq6qbFSEURZmSAxCJ6sYc+nXFzAQI8UBSzaAZnoIQA82vsKyWLNVM uy0IzwN2w5EvO/S0U1/nuWpFz6nXaRUsqGZmqu4Mqh5Sn1Trfrdp2NxAMDjHmOEZlGC5iaHa tQI1dQ+sZR502kFQdXNM75yqZnZY1dP+jPWnPfXLIP1eNzKn3syK5ZPve+8fuA2yFLI6i0gM mA3qM8BNoRol9Oqq2+85JEjLHOTEQRAlg4rOEAB1nPa6U3OdACSn71542d+f+08bNk9t3Nq7 /s4H/urvPvvI5k2h1a66vSMOO/TglSvZwICmPpMxOzPXdW3qzAhAYy2lqheF6n41NyNbRQhA 7vdU1YmNkEFOASwGSIjm5CIcaW4qqzrAUrYArpPXDlUNITTrQlVnCsEIYxPjnc5wqmtm7vbr 8771rV/c9/Dt9z/4ze9eWCUtQ7SqOmDfA4ZbUUJMCnNiCeomMdamzY628fC2itiOglxr1XMH 3JtfO0UoojB5qnq/jNCExgP91jPetOXJTdf89AaJhRmWL1t21NGv6ndnNFda9UW10ykxa9PU OcUQ65xCiCnXRQgg2V2/YH5ATuM2n1V9RIQjDj+00+nEdsc4tNrtXlX/4Ac/GBsbq/vVcCt+ 4Oz3LhwfKggOd/OiCKpuqiEwM+AuRGUUgVuuhjstollz3CEQglmqzXNVVQYEwksPXfWa4469 6tqfdjrDAF1x1dVXX/vTUMj2HdOxLGKr7E7vHG4Vv336aUVAYHSnq8AUA3LuC5PEgqUJsLd+ tyciTRgAcTAA4MYGEgIRZ01E1CzU7m45gT3Dk+Y5X6hp4kEgCvf7tQISxQFm9lQFISdnDgYQ IQS87uSTvnjueRKCM1+/5uc/u+nGwp2JorBWvXYhrz7qldQ4PqVxhVnONciKMgz4Q4Y66rou JcB8qNV2gkMIaOI2qa6ZuSzav5TQNNTykOC973r7ls2b7lq3LqDcb99lb3/zKTmhFSGA+4BA cMC82cikUphgIYQmypho4KWZS3wbzELANDuHQfSxOQu97rWvPf1UnuPu7nvo8WuuuiL1e57q 97znvYcdsn8YJEMReMBCxSLAHXAiYiDXVa675dDwzM4peAKQDcyAqfa67aGWmxWBm54L8Htv Pcs0/eiqn5StYSZRs9zTsizVrbdzauHY6Hvf+Y4jX3YwGQgY7pS97rSnJCHMdPvZOQOkiJHB klISl16vryQJ0AwJUAoppRhZ4KS54YM858BQMs11LMTdGzZGchJSckuzKc/ehNhr8nqGApB6 rrnpfCC85vhjbl5z451r74YwS1CwCOdUMaw/033zG954wquPcEcaMEK1W90uwtat21O/Z7N8 aqaojpxzzrlb9RWDpHqFmFNKydRn+r+cpmk0Q2QsHBn6k/e/99P/9TPrNz5SVz0ByojgcIAI 2dQgPEsBSuP/rxOySrvVZLwR7fIRY5dtYyLSpD2oughrtlbkRv001nN/ego5p6o+63ff8rrX vDoCmjMFrquqKNrmECEAWT0yOTkTLVm4YL99V7Q6beQFo502AGKYYXLxohcfsB/EUzUyMTpc ENQ8MC1Z2P7QB84+4rAXX3n1tY88+vh0r8vMATIx0nnJUS9/8xtOP2i/pZ4RAnI2BN5///1j awtCNFBZRAaEUSdfvmSREmcjdgy1SwJiQO1YuGB01f77MDNp6pSDqQhP+y5f7BzhNrlwXOua Q8nAskVjK5ctzVy4ptHR4YHjG1i2eMHBB+xbFEWq6oUTY0JgwAwTHfpPH/+zb//TBT+76abH n3pKiHLV7xRh2ZIlrz/llBOPP1YMxBCBOhZPThy47zKJcZ/J8cmJkWZFN8eypZMH7r9CRMR1 0fhIY6U5Y3LxotX7r1B4ITy5YOKXERqyrMQMNxD33e669/6/POdvVh2w+r984qPtxpWnycVB ApKG+BUYuhU4wnHJV75y2plnYqQDIQicGk0zm54CODIxA6zqMsuPW1YOjUGsHMubb7/zL/7j J09/4xnvP/tdAaBcD9yeZpBgzgqwgxnkqFMdi6KX3Brtl6pWEcDSTO5+LxchkDuxGzQGaRhT N4MRB6kMT27dum3L9qmpqeVLly5YMD7UaRcyIJYdUJAaOaFfo4hQoMUIKRMUQfpVLa1OlR2K VknNxjwI9+p+EVpm7llbraDauA/QS1ZErrKxWrsMyH0JkpIZly6oEoYiBEhJJUpVJ1Vtl7Gu 6yKUaOKWmtEVVMnV6dEnNk9NTQljqFOsXLFcyMktxGgOEBtQp1TGCKDfr8ooURhgBbo1iNCK 6M/0hjpFs7ODxF6VmSVE6nXrVlkU85wqzxWlQm7uZuQGYSPKoJ/dctvll1z6l5/4WHAgZ4TG 929MhTWkvmVyRjbM1F/+5H9euWT5iX98NkYjIoNFB7Eys+wUG+DmAy2Vsw02mTAzZREHX/mT a6+78aYP/emHO2XjQ8wDk2hWaGh3dl1VIaIAHEWzAZhdDwfHl5gBBuGstchscJcCzEak7kzM gCscLkxmiYUc7uBsYJYmBsCbRtUDOaCeExXRjIgD5q3a6lmomRUCQHOWGMwMxE6D1C4CNFdF wyeB1chECJDm/iaw35UarzrRIOwEMFUWMTcQGw26ZAoRCAyuIGRVkSK5CjWOnAzzgVMtJ4RY J2/ER9VDk9pqDiYzNM+i6vKMUNvnFJom1rPRAFmzhJDMN2zYsN8+K8qiWby0MWvNwMyDbEs3 9Gokv+Dff3zq1rVn/sE7h9/9O+gIuFCS5sHEHG6N0hmcJOKg5o3AAJgbMVeatm2dKmNcMDYx eCU0q6aA5wo1n8+VPvPfWWt8fj1z0T/zftwNu6JJnuXdzcYVPU+Xnr+fsy3uquQ5uvHL1vZc FT6jziZZfnYC7Lo4KPWrtD9bhojMbM6ZS0DBtHLFPkUcDLY57do9A8Ki6k6MQuB5QVEsTHrt V76587IfoW+oXRxwqDUrCsEHPGZj3oMIrvOfOEocnxgdHx0BDJbmPQw/zyPNMTvP+u+8f3jX Z94zPttQ8ax/7Omf2d6+QJeev5+zLfLTGvq/ru25KnxGnTxXdveLv/Kz7FbjXMKKiDSKJ8b4 zFTLwakRGUI0oKAsZ85DZWh1Z677X1/FtbcgOzICEBkpqcPBIHIzc7XZOS6DHvPgSxFazkGJ ax5k0+3Fngyef9DVXB5CIzpPO6JmfjKUNpvHMoYYq15/YWh1Nk9des5n8YvbkRO6FRliiERk lomcGTTLgTs85WQOAjWxnGTNYo3ZiJy92KPBcxol5wFNPWC2Zr83vzYADZJYmABmkIyNLgoU QmWLETpbnrrwr/8bfnErGEh9ZEN2YvfGHcPeRBMbEceoCgLIIBB25kyiJv4ra+y9+P+PXava HIM9tyTNVy2zkmTEGVpHKBSotTM84soRget6USg6T26+4K/OwS9uhzrcQE6N6akGM7i52tyJ jAOiymeNtNn49r3Yw8GNCpnTLk2ewFyq5dPuzv0eLMFqJEVWBFk0OWmO7ECIudtfnnh84+aL /9Nf4+qfIfWRZpAzUkY21IoMchbAshFBgUSwJlmz4Zkaj+xe7NkI89XJ0w7ynH+diOq67m/f 8eTatQslToQOOSDSmppuscApA4FC6OdlrfbmLdMXfvozxz7+9oWveCm6CRJn6np7XRXj44sO 2J/GRmPgjIGveeB4gDbb/r0ys+fjhU/3nDs7TVVlZ+/687558z9ftLBbL2m3U2/ncIztfi5s EC4TOKZUtYeHtvR2VC3xspU1zEh8OE0veOnBJ7/nXcuOfrmLmMwmF8w6K5pcSwZk76FGezx+ tSNh0c3oM6645rp//Mb0Aw8tiAgpCTM7cvIQCldjIq/rslP2Uj9J2EHFU8IvPf21L/r9s7Dv IgRCDANXamPcEEDmgKJJ8Nibnbun44WPT9tt461ADXR7eOKxW77y1Ycu//G+oSySW53K2CLi ul8xc1m2d3ZnyqHhR1K/WrX8xHe/bezEo9EpUAhEcjaRhqmaM4Eb8WkMmvCs/dmLPQe/otB4 k7VssD7qrJdeecV5X9MnnhpDLGtvkcDdmPqBd2TNrc7qE45ZffZbsc9ClBHiYFHQ4FQ953kb pVmvduN43atq9mz8Ugc1zr+oqhK4Rh0tswIPP3n/9y678wdXjG6bGao9R+dpAAAAtUlEQVS0 HaXLvsHS4pcffuJb385HvQIdQpMo7G5E5mBHYJkj5J7Ro3/ZB9yLf3m8wInl2N1b08QKZbhD AaOcSgT0gdvvWffN7z18y2319PbhfSZf8bYzh09+LcYWIDLIsqcQY1OdDVLDjSkMiMBdfflX esa9+BfGC5wjjGcTGocjpyABCmRFiKgzegk33/LoA/ftc/rJmBxFCKgDimIX70wEMyMQc25C LHY/cLqpfC+PsOfj/wBU44Dx023p5AAAAABJRU5ErkJggg== --B_3435318288_1212979-- --B_3435318289_1192483 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVmQYJKoZIhvcNAQcCoIIVijCCFYYCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EzEwggU0MIIEHKADAgECAhEAzuhISIgzOwSitfbc2LN4WDANBgkqhkiG9w0BAQUFADCBkzEL MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGll bnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMjA4MjgwMDAwMDBa Fw0xMzA4MjgyMzU5NTlaMCoxKDAmBgkqhkiG9w0BCQEWGXlpdV9sZWVAY2FibGUuY29tY2Fz dC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCscOeu5/EoYRdja1jb6L4x o0TIevelc17NsPuRHfr2z3BGUMbfsJY1p0uXO9+inBQoBXwb07ac3SbOjA/6Ef3NlMPItWdT RGeFL6e/sMju9RgVyJURFnFgp7tc2tffnPOupnKZeeRehXeEFjun6+GC6teb1kSMu+WMMaCa D7/XSK+Q+F0Udc2Av0/gUCkGfTDpNnYwutfctEMRnle6EYUqmJMN4C0crEfovmYdMFFgJLKs Wa5Cdc+naFoIqzW8AcZB6+1XUDTzFbgjqgUbFFZFPzVZqNxLDFNy4tn8VlRSp2jBhgwQHtk1 ZA+spFENaeUuebp4tczj0IHG683FhhWjAgMBAAGjggHpMIIB5TAfBgNVHSMEGDAWgBR6E04A dFvGeGNkJ8Ev4qBbvHnFezAdBgNVHQ4EFgQUz03csl7CmjwQY+spX9VWeGb5sVQwDgYDVR0P AQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEB AwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATArMCkG CCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEyg SqBIhkZodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlv bmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0 dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2Vj dXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAk BgNVHREEHTAbgRl5aXVfbGVlQGNhYmxlLmNvbWNhc3QuY29tMA0GCSqGSIb3DQEBBQUAA4IB AQBG7LORtWcmzDlw0N/D5AwfsSLe93essAqKFhJ+nt7SmMVBsxGzFnSsZGQHMYQ4UXtiVq9A NjtPk00F3DC3QGxe4mxdwF9LzeYHpHMpCHTzNyilSimKZolLNBO+MO/U0u79rdF2W+dOAwkB dzroWBxK+yMhijJn2DCE/1pgxqBz+c9zbAtJYPVpgbeGNvvfIp6CA/JYsupQNqPX49a4MdJ3 L9yXLTiegSE8uPUlCB3sHZclQOXAttuMewpcKDoIC4wZgERKQqRH61PQO100GLKUO+VrTq+f xNkjOAqA+dih6QO5Djbv3qcMTCcAChJQYK8BS7jved8XgEVa0Ihz7oWKMIIFGjCCBAKgAwIB AgIQbRnqpxlPajMi5iIyeqpx3jANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJU UlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNV BAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0x MTA0MjgwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMS R3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8g Q0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoSEW0tX mNReL4uk4UDIo1NYX2Zl8TJO958yfVXQeExVt0KU4PkncQfFxmmkuTLE8UAakMwnVmJ/F7Vx aa7lIBvky2NeYMqiQfZq4aP/uN8fSG1lQ4wqLitjOHffsReswtqCAtbUMmrUZ28gE49cNfrl VICv2HEKHTcKAlBTbJUdqRAUtJmVWRIx/wmi0kzcUtve4kABW0ho3cVKtODtJB86r3FfB+Os vxQ7sCVxaD30D9YXWEYVgTxoi4uDD216IVfmNLDbMn7jSuGlUnJkJpFOpZIP/+CxYP0ab2hR mWONGoulzEKbm30iY9OpoPzOnpDfRBn0XFs1uhbzp5v/wQIDAQABo4IBSzCCAUcwHwYDVR0j BBgwFoAUiYJnfcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4Y2QnwS/ioFu8 ecV7MA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYE VR0gADBYBgNVHR8EUTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVT RVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRo MGYwPQYIKwYBBQUHMAKGMWh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENs aWVudF9DQS5jcnQwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJ KoZIhvcNAQEFBQADggEBAIXWvnhXVW0zf0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtz bj7pJnzmTJjBMCjfy/tCPKElPgp11tA9OYZm0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqT ecr+4pEeVnSy+I3T4ENyG+2P/WA5IEf7i686ZUg8mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPN M1+b0L1garM7/vrUyTo8H+2b/5tJM75CKTmD7jNpLoKdRU2oadqAGx490hpdfEeZpZsIbRKZ htZdVwcbpzC+S0lEuJB+ytF5OOu0M/qgOl0mWJ5hVRi0IdWZ1eBDQEIwvuql55TSsP7zdfl/ bucwggSdMIIDhaADAgECAhA0PekrrCc0/4/LNJT7zHBUMA0GCSqGSIb3DQEBBQUAMG8xCzAJ BgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0 ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3Qw HhcNMDUwNjA3MDgwOTEwWhcNMjAwNTMwMTA0ODM4WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNV BAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMT LVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjM apjVTTUZuaRC5c5J4oovHnzSMQfHTrSDZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKT zMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1lepS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZG zaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGoLhu21DEgLLyCio6kDqXXiUP8FlqvHXHX EVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0YqoYymiTHqGFfvVHZcv4TVcodNI0 /zC27vZiMBSMLOsCAwEAAaOB9DCB8TAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73gJMtU GjAdBgNVHQ4EFgQUiYJnfcSdJnAAS7RQSHzePa4Ebn0wDgYDVR0PAQH/BAQDAgEGMA8GA1Ud EwEB/wQFMAMBAf8wEQYDVR0gBAowCDAGBgRVHSAAMEQGA1UdHwQ9MDswOaA3oDWGM2h0dHA6 Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFsQ0FSb290LmNybDA1BggrBgEF BQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZI hvcNAQEFBQADggEBAAG8nONjKLDzMQHC33vdYqABnSMxD5ySc1NR6h9M+tafxMovZ354Mw90 FrmRh5H1iib6ZHAA2B75CwRiUIeTgdTa9SPbNLuFVrRwNG54gzcehRzFERWSX4cXvaxq/fHC 0cyJX7F88D5R8jXzfOxgmGs6K+Dv37N9huu1G/Vb7KJ8mBPXAFC50S1z3gN4dOEFhTFey5q5 nZTGuZQ3dXLcRPtn6PD6JR5Sp9ol6UfgoMc8oE6xCjb7d0if75eK+7T+45QUqIO8XC0/0mBx YO7CcYIM6Yg249ogtKOgbKqWS7iAjnXKSQf2OxS639wF2Z/b4LLmTaB4JufnLW5/X8YeiBUw ggQ2MIIDHqADAgECAgEBMA0GCSqGSIb3DQEBBQUAMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQK EwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsx IjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMDAwNTMwMTA0ODM4WhcN MjAwNTMwMTA0ODM4WjBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAk BgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVz dCBFeHRlcm5hbCBDQSBSb290MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt/ca M+byAAQtOeBOW+0fvGwPzbX6I7bO3psRM5ekKUx9k5+9SryT7QMa44/P5W1QWtaXKZRagLBJ etsulf24yr83OC0ePpFBrXBWx/BPP+gynnTKyJBU6cZfD3idmkA8Dqxhql4Uj56HoWpQ3Nea Tq8Fs6ZxlJxxs1BgCscTnTgHhgKo6ahpJhiQq0ywTyOrOk+E2N/On+Fpb7vXQtdrROTHre5t QV9yWnEIN7N5ZaRZoJQ39wAvDcKSctrQOHLbFKhFxF0qfbe01sTurM0TRLfJK91DACX6Yblp algjEbenM49WdVn1zSnXRrcKK2W200JvFbK4e/vv6V1T1TRaJwIDAQABo4HcMIHZMB0GA1Ud DgQWBBStvZh6NLQm9/rEJlTvA73gJMtUGjALBgNVHQ8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB /zCBmQYDVR0jBIGRMIGOgBStvZh6NLQm9/rEJlTvA73gJMtUGqFzpHEwbzELMAkGA1UEBhMC U0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBU VFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdIIBATANBgkq hkiG9w0BAQUFAAOCAQEAsJvghSXC1iPiD5YGkp1BmJzZhHmB2R5bFAcjNmWPsNh3u6xBbEdg g1Gw+TI95/z2JhPHgBalv1r8h894eYkhmuJMBwqGNbzy3lHE0pa33H5O7nD9HDnrDAJRFC2O vRbgwd9Gdeckrez0QrSFk3AQZ7qdBjVKGNMresxRQqF6Y9Hmu6HFK8I2vhMN5r1jfnl7pwkN QKtq3Y+Kw/b2jBpCBVHURfWfp2IhaBUgQzyZ53y9JNipkRdziD9WGzE4GLRxD5rNyA6eji4b 4YyYg8sfMfFETMYEc0l2YA/H+L0XgGsu6cxMDlqaeQ8gCi7VnmMmHlWSlNiCF1p70LzHj06G BDGCAjAwggIsAgEBMIGpMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5 MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBAhEAzuhISIgzOwSitfbc2LN4WDAJBgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFHqu nYLByOWuVneb9/5felTwE072MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTEyMTEwOTIwMDQ0OFowDQYJKoZIhvcNAQEBBQAEggEAdhjkZDIkHIES1JSs2R4e 7K2rVegNoaxTNy45KWGnaMFF46uu1rwn+lnnrUsoNHSxZ0ordUCfx6QG3tpALF9g6Z9LLbb3 n09WruioQCK6GJedGJXqhjoy5JnaWXdHyESa0LLeoIinZo6gb0nAkgrcVos9Bae0XV13LMQ6 1FNBsJhY35XIeuF+u3tZwieQm3NEVHAiGso+LQVoDInGdE40Z/2yZTSERPv2HRkWebU5s/Jp BOX85iJAVFxwn9alwUH0VzcBzcz5yw/OErfpuDBvLg6YqX5tWvldnxahtOzfF4jHGFkK+95d ftLDqPYT4LoBX08aiebrHAs/QPw9wadxWA== --B_3435318289_1192483-- From akostur@incognito.com Fri Nov 9 16:13:41 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 3DCEE21F848B for ; Fri, 9 Nov 2012 16:13:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 DMrrjFbe7sIj for ; Fri, 9 Nov 2012 16:13:40 -0800 (PST) Received: from na3sys010aog113.obsmtp.com (na3sys010aog113.obsmtp.com [74.125.245.94]) by ietfa.amsl.com (Postfix) with SMTP id 4916F21F8493 for ; Fri, 9 Nov 2012 16:13:40 -0800 (PST) Received: from mail-oa0-f70.google.com ([209.85.219.70]) (using TLSv1) by na3sys010aob113.postini.com ([74.125.244.12]) with SMTP ID DSNKUJ2cM03fEIED/yaHM8aakq53HLsKbsP1@postini.com; Fri, 09 Nov 2012 16:13:40 PST Received: by mail-oa0-f70.google.com with SMTP id k14so14130877oag.1 for ; Fri, 09 Nov 2012 16:13:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=SZt2CHESFcXx7qSbd6RhDErLoyof26sNGMnrUQbqYLk=; b=if8Lve8T03rmJmyyWjcrl0wOjNUnkmXRnyl1/SNmJDvH3UzaaTO5FsLEeB86rpISeP suB2XV7d4jyvB+FPE58j6uRzwXSg+Tjj3E8IIW32Ag98qG+lsLmq4Mfsx1Ni/cHPmLAx Iy+5qFsC5B9xiF7zDiIh9v6RfksvFDoGK680bo2JU7Cdvk9TFC42n53IBVrxUlbJ/aQv VfDHj7k9Q+9rkajMhuQ3QMkG1SzY5cSxjLvbiHdJMlSz2d/6d53M0LXtLsX9Y57udUIK IwtkbtZoNkEyxD7jeMJH6VBq7bdbdo1apTsp7L3jIa12kUXCWp1Jkg6gT+QwZdRpW14n qYOQ== Received: by 10.42.68.14 with SMTP id v14mr11876855ici.16.1352506419047; Fri, 09 Nov 2012 16:13:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.68.14 with SMTP id v14mr11876840ici.16.1352506418961; Fri, 09 Nov 2012 16:13:38 -0800 (PST) Received: by 10.64.51.3 with HTTP; Fri, 9 Nov 2012 16:13:38 -0800 (PST) Date: Fri, 9 Nov 2012 16:13:38 -0800 Message-ID: From: Andre Kostur To: "dhcwg@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnxJkuRP1A0zLWUteA7vg+f1BcoM9QooQP/xBE161VYACW8J+eAjvWQAV79J1N9e2DcymncWBxgN+EwqNEP87UtuZ7TFsD8ftZaYMpl8bUL5ynkLHigql8/hxZCga+52z2fiP69RcE/kc7fQZqv1LTGzlyywQ== Subject: [dhcwg] Load Balancing for DHCPv6 -03 X-BeenThere: dhcwg@ietf.org 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, 10 Nov 2012 00:13:41 -0000 Dear all: I have submitted an updated I-D updating RFC 3074 to apply to DHCPv6. The text is available at: http://www.ietf.org/internet-drafts/draft-kostur-dhc-loadbv6-03.txt Major changes: Fleshed out Section 3.1 to discuss the messages with a Server ID specified. No remaining outstanding items that I'm aware of. Comments and suggestions welcome. I am looking to have the WG take this on as a work item. -- Andre Kostur From bingxuere@gmail.com Fri Nov 9 20:20: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 A564E21F86B8 for ; Fri, 9 Nov 2012 20:20:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.577 X-Spam-Level: X-Spam-Status: No, score=-3.577 tagged_above=-999 required=5 tests=[AWL=0.021, 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 3+9HhNLby7Bh for ; Fri, 9 Nov 2012 20:20:52 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2C4EA21F8755 for ; Fri, 9 Nov 2012 20:20:46 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id 9so7634186iec.31 for ; Fri, 09 Nov 2012 20:20:44 -0800 (PST) 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=QpKGbXLVgdGtXb6wLwQFJwzLrDVdIyTowcYEI1mAcEA=; b=d2XgPrtm2KXZPWy1E7AVO+26VxnQkPXu5AFGrYgz3FEIYCENOZLLl+NPXP/NMF6t7h YvIKn7rjNGRW2WZ5eQtfxcgWWlmfRCYoENghXBGDG4fVt8VaaaSrJCnNk9XTwvgQs+xW F7NRFKuRN5thFJLzB8D/omlBDfKqkDDXJE0LuYczOGkBVm3o6RPRZ+rr4YGbnItJK7fI TFdlhNnWnrDbrHAph23L72vhnmJiK/wr1cl4u+HYAm8wBjopLQwn+7tL70uVT6+IoJDn M/De37G4K2BCuagNuONe+c6lgMZJ3EQZQFkS2/xkwXP6CMWuxyPluAPrOM2FiRnGga2G nI3A== Received: by 10.43.120.3 with SMTP id fw3mr13492147icc.34.1352521244217; Fri, 09 Nov 2012 20:20:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.76.200 with HTTP; Fri, 9 Nov 2012 20:20:02 -0800 (PST) In-Reply-To: References: <03A575EB-4646-4492-8B9C-40A9CA15069B@nominum.com> From: Qiong Date: Sat, 10 Nov 2012 12:20:02 +0800 Message-ID: To: "Lee, Yiu" Content-Type: multipart/related; boundary=bcaec517cb525013a404ce1c6463 Cc: " WG" , Ted Lemon 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: Sat, 10 Nov 2012 04:20:55 -0000 --bcaec517cb525013a404ce1c6463 Content-Type: multipart/alternative; boundary=bcaec517cb525013a104ce1c6462 --bcaec517cb525013a104ce1c6462 Content-Type: text/plain; charset=UTF-8 Dear all, I support this work to move forward ! Best wishes Qiong On Sat, Nov 10, 2012 at 4:04 AM, Lee, Yiu wrote: > I also support to move forward. > > Thanks, > Yiu > > From: Mathias Samuelson > Date: Thursday, November 8, 2012 10:27 PM > To: Ted Lemon > Cc: " WG" > Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv4-over-ipv6 > > Hey Ted, > > I support advancing this. > > Thanks, > Mathias > > On Nov 8, 2012, at 5:26 AM, Ted Lemon wrote: > > On Oct 18, 2012, at 10:05 AM, Ted Lemon wrote: > > 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. > > We will evaluate consensus on November 1. > > > There was one response in favor of this WGLC. The document got > substantial support in the previous WGLC in June. Has that support gone > away, or did people just not respond because they responded to the previous > WGLC? If you want this document to advance, please do respond to the WGLC. > > Thanks! > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > > > Mathias Samuelson > Sr. Product Manager > > m: +1.650.491.4193 > o: +1.650.381.6225 > mathias.samuelson@nominum.com > > > > www.nominum.com > What is IDEAL? | > Like | Link | Follow > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > > -- ============================================== Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/* PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * =============================================== --bcaec517cb525013a104ce1c6462 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear all,

I support this work to move forward !

Best wishesQiong


On= Sat, Nov 10, 2012 at 4:04 AM, Lee, Yiu <Yiu_Lee@cable.comcast.com= > wrote:
I also support to move forward.<= /div>

Thanks,
Yiu

From: Mathias Samuelson <Mathias.Samuel= son@nominum.com>
Date: T= hursday, November 8, 2012 10:27 PM
To: Ted Lemon <Ted.Lemon@nominum.com>Cc: "<dhcwg@ietf.org> WG" <dhcwg@ietf.org>
Subject: Re: [dhcwg] WGLC: draft-i= etf-dhc-dhcpv4-over-ipv6

Hey Ted,

I support advancing this.

Than= ks,
Mathias

On Nov 8, 2012, at= 5:26 AM, Ted Lemon <Ted.Lemon@nominum.com> wrote:

On Oct 18, 2012, at 10:05 AM, Ted Lemon <<= a href=3D"mailto:ted.lemon@nominum.com" target=3D"_blank">ted.lemon@nominum= .com> wrote:
The authors have requested= a new working group last call on this document. =C2=A0=C2=A0The document h= as been updated based on feedback received during the previous working grou= p last call. =C2=A0=C2=A0The authors would appreciate review and feedback o= n this document. =C2=A0=C2=A0If you favor advancing it, please say so on the= mailing list. =C2=A0=C2=A0If you oppose advancing it, also please say so a= nd say why.

We will evaluate consensus on November 1.

There was one response in favor of this WGLC. =C2=A0=C2=A0The document got = substantial support in the previous WGLC in June. =C2=A0=C2=A0Has that supp= ort gone away, or did people just not respond because they responded to the= previous WGLC? =C2=A0=C2=A0If you want this document to advance, please do respond to the WGLC.

Thanks!

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

Mathias Samuelson
Sr. Product Manager
=C2=A0
m: +1.650.491.4193
o: +1.650.381.6225
mathias.samuelson@nominum.com



www.nominum.com What is IDEAL?=C2=A0 | =C2=A0
Like=C2=A0 | =C2=A0Link=C2=A0 | =C2=A0Follow


_______________________________________________
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
China Telecom= Beijing Research Institude


Open source code:
lightweight 4ov= er6: 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

--bcaec517cb525013a104ce1c6462-- --bcaec517cb525013a404ce1c6463 Content-Type: image/png; name="5835B47C-5F26-40DA-AB76-6EEE8615A3A5[6].png"; x-mac-type=504E4766 Content-Transfer-Encoding: base64 Content-ID: <8248574A-055C-4AC6-BBDD-3B293A856454> X-Attachment-Id: b7d6511b76037fa4_0.0.0.1 iVBORw0KGgoAAAANSUhEUgAAALwAAAAvCAIAAADW2TcRAAAKWmlDQ1BJQ0MgUHJvZmlsZQAASIm1 lgdQFGkWx7/unhxIQ45DzjmD5DigkqOoDDNkGIchCIgKyuIKrAEVETCASlRwVeIaEFFQWQQMGNAF WQTEczEAKirXwIF7dbd1dVV3r+p1/+pfX78v9Peq/gBQmplcbhwsAEA8J4nn7WJPDwwKpuMHAQyo gAhkgR6Tlci18/RcDf4yZh4CaOF9T3uh1l+P+7chyA5PZAEAeaIcxk5kxaN8EeV3LC4vCQC4CuXe zUlclJFUlIV56AJRzl/gyCU+scBhS3xxcYyvtwPKXQAQKEwmLxIA8n1Up6ewItE65A8o63HY0RwA KEooW7OimGyU0QRa8fGbFngfymphf6oT+U81w1ZqMpmRK7y0l8UgOEYncuOYaf/lcfzniI9LXp5D CE0KJ27twr8hoTnOZjq6LzM3znNFD+f4+SwzJ2ytxzJH8Jy9V8Yn2f+JPX2XOT3KYe1KnUSnlTox TDfPZeYle/stc2KKj9P3b30DVtYW7riiR0Q7M5Y5OomxMlfsJveVNQB/YACMgCFwBSApPDVpYcMO m7hpvOjIqCS6HXrTwrXoDA5LR4tuoKdv8D8/5/9nLPTYEr1/tNg7kCjhu5ZWjV7Jo6iY+10LLAOg zhEAsYbvmhLaAzSUW96wknkpSxpm4YFFT5AfCAMJtH8VgRrQRk/SBFgCW+AE3IAH8AVBYANggSgQ D3hgM8gAWSAH5IF94BAoBsfBSVAFzoLzoAlcAtfATXAH9IIH4CkYAqNgEkyBGTAHQRAeokI0SAKS g5QhTcgAMoOsISdoNeQNBUGhUCTEgZKhDGgnlAcVQMVQGVQN/Qy1QNegW1Af9Bgahiagd9BnGIEp sDAsA6vAurAZbAe7w77wejgSToDT4Wx4D1wEl8Nn4Eb4GnwHfgAPwZPwNAIQMiKKyCPaiBnigHgg wUgEwkO2IblIIVKO1CGtSCdyDxlCXiOfMDgMDUPHaGMsMa4YPwwLk4DZhsnHFGOqMI2YDsw9zDBm CvMNS8VKYzWxFlgGNhAbid2MzcEWYiuwDdgb2AfYUewMDocTxaniTHGuuCBcDG4LLh93FFePa8P1 4UZw03g8XgKvibfCe+CZ+CR8Dv4I/gz+Kr4fP4r/SCAT5AgGBGdCMIFD2EEoJNQQrhD6CWOEOaIA UZloQfQgsolpxL3EU8RW4l3iKHGOJEhSJVmRfEkxpCxSEamOdIM0SHpPJpMVyOZkL3I0OZNcRD5H 7iIPkz9RhCgaFAdKCCWZsodSSWmjPKa8p1KpKlRbajA1ibqHWk29Tn1O/chH49PhY/Cx+bbzlfA1 8vXzveEn8ivz2/Fv4E/nL+S/wH+X/7UAUUBFwEGAKbBNoESgRWBAYFqQJqgv6CEYL5gvWCN4S3Bc CC+kIuQkxBbKFjopdF1ohIbQFGkONBZtJ+0U7QZtVBgnrCrMEI4RzhM+K9wjPCUiJGIk4i+SKlIi cllkSBQRVRFliMaJ7hU9L/pQ9LOYjJidWLjYbrE6sX6xWXEpcVvxcPFc8XrxB+KfJegSThKxEvsl miSeSWIkNSS9JDdLHpO8IflaSljKUoollSt1XuqJNCytIe0tvUX6pHS39LSMrIyLDFfmiMx1mdey orK2sjGyB2WvyE7I0eSs5aLlDspdlXtFF6Hb0ePoRfQO+pS8tLyrfLJ8mXyP/JyCqoKfwg6FeoVn iiRFM8UIxYOK7YpTSnJKa5QylGqVnigTlc2Uo5QPK3cqz6qoqgSo7FJpUhlXFVdlqKar1qoOqlHV bNQS1MrV7qvj1M3UY9WPqvdqwBrGGlEaJRp3NWFNE81ozaOafVpYLXMtjla51oA2RdtOO0W7VntY R1Rntc4OnSadN7pKusG6+3U7db/pGevF6Z3Se6ovpO+mv0O/Vf+dgYYBy6DE4L4h1dDZcLths+Fb I02jcKNjRo+MacZrjHcZtxt/NTE14ZnUmUyYKpmGmpaaDpgJm3ma5Zt1mWPN7c23m18y/2RhYpFk cd7iD0tty1jLGsvxVaqrwledWjVipWDFtCqzGrKmW4dan7AespG3YdqU27ywVbRl21bYjtmp28XY nbF7Y69nz7NvsJ91sHDY6tDmiDi6OOY69jgJOfk5FTs9d1ZwjnSudZ5yMXbZ4tLminV1d93vOsCQ YbAY1YwpN1O3rW4d7hR3H/di9xerNVbzVreugde4rTmwZnCt8lrO2iYP4MHwOODxzFPVM8HzFy+c l6dXiddLb33vDO9OH5rPRp8anxlfe9+9vk/91PyS/dr9+f1D/Kv9ZwMcAwoChgJ1A7cG3gmSDIoO ag7GB/sHVwRPr3Nad2jdaIhxSE7Iw/Wq61PX39oguSFuw+WN/BuZGy+EYkMDQmtCvzA9mOXM6TBG WGnYFMuBdZg1ybZlH2RPhFuFF4SPRVhFFESMR1pFHoiciLKJKox6He0QXRz9NsY15njMbKxHbGXs fFxAXH08IT40voUjxInldGyS3ZS6qY+ryc3hDiVYJBxKmOK58yoSocT1ic1JwqiZ6U5WS/4heTjF OqUk5eNm/80XUgVTOandaRppu9PG0p3TT2/BbGFtac+Qz8jKGN5qt7VsG7QtbFv7dsXt2dtHM10y q7JIWbFZv+7Q21Gw48POgJ2t2TLZmdkjP7j8UJvDl8PLGdhluev4j5gfo3/s2W24+8jub7ns3Nt5 enmFeV/yWfm3f9L/qein+T0Re3r2muw9tg+3j7Pv4X6b/VUFggXpBSMH1hxoPEg/mHvww6GNh24V GhUeP0w6nHx4qGh1UfMRpSP7jnwpjip+UGJfUl8qXbq7dPYo+2j/Mdtjdcdljucd/3wi+sSjMpey xnKV8sKTuJMpJ1+e8j/VedrsdHWFZEVexddKTuVQlXdVR7VpdXWNdM3eWrg2uXbiTMiZ3rOOZ5vr tOvK6kXr886Bc8nnXv0c+vPD8+7n2y+YXai7qHyxtIHWkNsINaY1TjVFNQ01BzX3tbi1tLdatjb8 ovNL5SX5SyWXRS7vvUK6kn1l/mr61ek2btvra5HXRto3tj+9Hnj9fodXR88N9xtdN51vXu+067za ZdV16ZbFrZbbZreb7pjcaew27m741fjXhh6Tnsa7pnebe817W/tW9V3pt+m/ds/x3s37jPt3Hqx9 0PfQ7+GjgZCBoUfsR+OP4x6/fZLyZO5p5iB2MPeZwLPC59LPy39T/61+yGTo8rDjcPcLnxdPR1gj k78n/v5lNPsl9WXhmNxY9bjB+KUJ54neV+tejU5yJ+de5/xN8G+lb9TeXPzD9o/uqcCp0be8t/Pv 8t9LvK/8YPShfdpz+vlM/MzcbO5HiY9Vn8w+dX4O+Dw2t/kL/kvRV/Wvrd/cvw3Ox8/Pc5k85qIV QNCEIyJQK10JADUI9Qq9qLXiW/LAiwEt+fZFAn/FSz55MUwAqLAFwD8ToDYCgFI0lTOXbKgnqvva AtjQcCX/EYkRhkvmDCI3odakcH7+PeoJ8eoAfB2Yn59rmp//WoEu9gkAbTNL3nvRx/DQx0kktCar 6/Tkv/invwNLKeWav6IXrwAAIABJREFUeJztfGu0ZVV15jfnXGvvc8591+PWgwKKokAEBeMDCPJS QCKokWDwmRgjMW2bdsS0Go3dbTuSNqPpmI7dI7ZRG0SNr0QFQR4KIiDyKEHeRQEFFMWzqqiqW3Xv OWfvteac/WOfe+sWT+1OepRj1DfOuOPcffZ67L3mmmuu+c25yN3x3HB3Imq+uDszO5DdmBiAZUQB rIYquoq71+GhjfjNozA5gpaAYyKp3QNxdLADBCckAAADAlDTOMEBAwDI8/RmL/YM0AsKTSMru64A yVRYoCouSArPWP/QnRdefMePr7Xp3v4vPviIN/3WyGuPRbtEEZSDAwGAwbNlco4CgAFqqht0BLPy sxd7Ol5AaDBP2QAwuMOT5Ugs5phJ2Da95YJLbrzgYt4+M8ZB1Huq0yUvPvyQo979u3jFS9AqENgr pRBBAPFutdu877xXZH498JxC01yfE5cGZkbkBEdy9JNedd1VX/562vDYuFKZTbJ1Yrufk8aws0VP DYcX/9ZrXvTWM7FkEYQhAJNnIxFXpxDm1Qtgr9D82uD5NI2ZzS1MA33jQF1DCRueuO/8bzz442vb M72hKAXIcg5gJCuKVl+rmr2GbScsevGhrzzrDJx0FIYFkQ3ECAAcrE0rs9IiAHyv3Pwa4JcSml3S o4badlx9wzXnfT3dv2GR+ihR7k63ighAmJHcs3IM6kaldIHNfasmJ150xusOecvpWLpAYcQRTA7x eavTwC7+13/gvfh/x/MJzZw1o6oiAgBbd1z/1e/c9J2Lhqs0wgg5dVJeQFyqknmu00i7oymTOdrF E9rtlbGHcppoBpg8/JCTzn7n2CtfmtwolgTMt25soGWMwXtFZw/H89k0cwZNIzSqOv3I41t+ftc+ ZacFQq4xPoTNW27+5ws2r123QMo2KPerViy0n1Mpvmry5X/0XkiBKoNkU286T44vf9XhPjLchxVg AWCz6oWsWa32Cs2eD1LVpxsuu0vM7jCowoFKwQRLcMKTm2787OefuPbG5dxCSsEpOvfKkFZOHvPZ czA2hCKAGEQghnAmNPJRAKQOJ1hGZFDT7l5PzZ4OZmZ3zzmb2ZygPIfEwIFaKAegE1BGbZVoR+yz 9KgPf3D1ySc+4nUuS2OGlDNV3tbtY2YGZUApWohGRmAnAJDZtclzBhyBoQoY0Qvs//diT0BolEqY 3QC7e2P2PqvcEFAAcIIynDmyA6QZixcd9uH3dyM9fulPl5pUSTtDw1OVYmcfKrAgTeFZiQEABwEo IgBoRpAq9SXGvebwng82m+9fAxGJyHNpGgBwICvAYNQZCoADQJgYfdUHzj7wta/eRGatIqmlbo1e BedBKQccNPcBsmYjd4LCARSxtbtxvBd7KHiwLQLMrDGKG2XzfIWcIHABADdAgLKAAgsXHPbRfzd6 zOFPeSLmUCf0KhCUkQXKgAMKKODmBA+SmwpC0Zvpk3OA7FUzez4GbhgAc+YwETWGzrPc7gwwipAs GxBmB1nV0GojRLTl+I99qHPIyk02E1oRdR/YRUaCADKQAXAowRkMQN3aQx1kH+y892LPxjwmclZK cs6PPvro/Cu7QEg5ORCE3ZQbntEhgTMhBWB4CJMLjv/o+23V5GafARtgASgAAZzMxVwMbAwnVZgC 2PzUtm4vIezVMr8e4IFgOIgIRMnxi7vuOv8fv+mN4eq7pn7zNcRobg4PTAQjEOAOJHdDABMi4eCV p//JH02PtLQQsM8ZNAYo2MAOBiCgwALgnnX3fe4LX6gNhl/BDPZ5HwUykJul72l37F5EZ2/T2Zuf R7X5vBX1aUWe2e6zNuq7fwCb/TxL5c/TGX/Gr3PF/dl+fdb++zM6v3u7tjuBPKjhmU8RCCAa2KqJ 8OBjj37mc/9wwP6rjBCaWwarCQxsjkDMNDuyjZFLBEIEGaAOCQEFl0cdefx73r11qL1YCGSuIGHL CIFp1n7iWXOqMzLyw59c01mw5A9/7y0RYPd5e292QBUiSHUuiqar7mBtrHXHpq0z03W9c2a63S6X TC4aYi4FUBs8lhkxO1hNwVIDU13d/OQmS3m4M7Rs6YKCERjmxgRzA3gQLWQAQ4FNT+2YmtrJFIp2 XLRgoiwoAO7YPtXdtG2HEkngZYsXTJRCrnNS704gUqB5LZGQc2oFAhxOIPQTJPLWHXnr1Pa6rkaG 2qNDrYmRjgA0N3jOIKRsHLgZ3RJwy+CQgexggjmaESEgAKoeZBB1sm2q++TWLSAhCcuWLGkXYEDV ut3upq3bqzq3h4bHx8dHOiECMssbO2AGd1dVhQdiCtK4XNUgjGAGFuRaQyFPbNry1+d85omt2w95 yagC7ogAwIA1G+Sm5NN1wexFyykGGZQo+Yg3no6qahhJdQvgKAxHyhqjNJ3LDgekaI+ML/z+Dy4f HZs4600nAc7uRKQ5SyhyBgeYoSgCXGEKCU2rd6576NJLfrj2/nu37tjpQCyLseGho1/+sjNOf/2S hWOaskjj8mYDjOWa69dcftW1Dz68kZx7M91OqxgdGXrlyw4/7XUnLVu6mAEiIlB2EAGMG9bcdtHl P3pw48b+TK3usZAlSxaf8cbTl04uuuTiS++8a+3OSiGBY1iyaPTolxx25htfPzYynOo6lgUI69Y/ 9KXzv+xciMjkwrF/+76zHe5qLNGcH9+0+fxvfHvDI09s2boNpo60ZOHE4Ye96Mw3/faKpYvrqirL 0oENGx798te+Vim6dVq8cOLP/s3ZrTI68MTmrZ//4rlVVbn7yMjI+//4fROjbQVISIF77n3gO9+7 8KGHN+6c7vZzlqIcHh4+8bhjj/nNo6++8oc33XTTzl5d1UnKztBQ+8jfOOLNbzx1v8ULCZZNhYUI Tzzx5Np711VVdeCBB65fv/7lr3jVxMTE2rVrq6oKjR9fCtk61f37z3/hyc3b2q1h4agYzDMGVImE HFC1UhhAs77YPPFhoBUiHLCMZqM0VKDkJoAmhGAGJpghBjGHE5KCBQa0h0ame/2yNfztf/7uoonh 17z6qIKhqhIKAI2BPjDTiSDBnYxw1U/XfPG887dOzQyPjjBzzjnXuump7d/9weU/v/2OT/75R5Yt HheAXRTYWdnnvnTudTfeKFxWdS7L0oinulW3Tt+79LLrbrzpfX/w+8cc+TIoWBAIyfG9iy49/xvf MokkZYwlGWq3DY9t+Zu//8Lo8HDd7ZtB2q1ur4Ja/fjWB9f/4J77Hvjohz44MdbOAIAadMc96zm2 TNOKpZMUggEQ1I7b7lp3zt/+jx0zlRO3Ox1Th4dt0/2Lf3T1Lbet/fhH/uzglfs4YITkdMsd93DR 2tnr77N8UkN0ZgPU+PY718KZiEaHO0KBgaxgwZpb7z7nb/87h9ivUlm23UM22j5TffeSH1125TU7 d2wnIiKSWPbV+zu6F1z+4zW33v6JD39w9X7LeXbxWLpsstVqbdq06YADDrj77rsffOD+ySNfde+6 datWrQrOUKDKOPdrX7/j7vtC2crmjz+56dvf/7GnfupOV71uYJx22utXLF9SyC7Def5GhwBTFZaB /AgAVKlfxILAqirCc2PvhIsuvvyhRx4t252i0yaOO3t9KUpiqer6/K9+fZ9lSw9ZvT+LqIEZzEjm AJmmGMVUSeJT23Z+7Zvfmprut8fGe71e8FwWITmK2FLihx598vPnfvkTH/nTwDBH7Tjvq9+4+mc3 gAPUA3Fd9dpDneluSg4p2tunu3/3Pz83/omPvfRFq3ICRdx7/4Z/uvAiCiWxMPP09HS73a5rLdtF pbnKLiEKUXemOzwyPFP1U0pla+QXd637x29/54//6F0EqCEbx9YQKIIlxFa/tlhwpUiGfzj3K9um q87QkKlqzpqSE4gpFMNbd/b+91e+/qm/+EhguEOJKbYRy+DsCP0qtWIJIOdcxJYaAxRDmx1uCIIn t+783JfOTVyoGkLR7fcCiznllCQUO3sVxbJTlnXVg3nOqSjbodXZtHXqH750/qc/9fEIMMHhRKSq MzMzQXj58uUxxjU/v3nVqlWtViuAkIALLvnhVdffJOVwv6rLTvvBDY/cc+/9geFWF8wl0XEnntAs 88J4mguu4auJBeaNXJhlZ9YQEljA1JBKTUAwwYBb77zrmutuaA0PVwqXUBSlxNZ0tzs6NLR95/Tn vnjep/7Dx8aHW42I5mwxMAHCMacqxFibX3n1NVt3TIfOUFYfGR97xxlvWLnfihvW3HrRZT8KnQ6H ePe6+5/YtHW/yQVmWHv/w5dd+RNutQGI2vHHH33KKSeHIj644eELLrr4iU1bcq1w+/q3vvPJP/9I 2UIv+bXXX79jpo7tDmm1eHzsPR/8k1ardcVPrr72+p+1y8JNNaXJRQs+8L73jI2P//jaq2+4cY1m tDpDN95885lnnTk51haGmjtCVhCHGIIQG8CC6268dcNjm9sjI3W/Gum0zjzjt1evXnXbnXddeMkP nbhX1Xfee//6Bx968UErCWCJxpKyGYuDRWYnrjmHWCdT9dq8GZWsuO2O27fv7GYJTjLUar3zjLcf uP/+t91220UXX5pASV2CuOV3nvU7hxy8+pY777740h/mXm7FYsOGDevWrT/8kAMbKxBA1np4pAOD Z122z4o1a9Yce8LxGzZsCA7cfc/93/3+9zMFdh4ZW9jtdkkkttvmSiYsrKkeGR4b2DQOEOYHNuwK 9SXCbLxfcg0UFOpqhQQCYO6gnJ0jjS9YOLpgkXKklDjEBK+qenx8fMfUVLtsPbjxsS+e95WPfPB9 Tf0hMICUUggcYqzrzEWxZfvOXqWhhV6v+5Yz3nD6KccRcMiLDrh/wyM33X5Xq9Wa6U2vW3vPfkuP IcZlV1zpYHW45lNPPO59f/gOAoSwesXiAw9Y+alPnzOtXTO68557H9z4yMEHrQiR1t33QHKKxAx6 21m/e+RvHEzAvvu+Y+26u5+ammYiM3vbW848/jdfRsBBB69cv379xo2bQojdOj366KOLxlbTLHES itLqKvUr8oERvPGRx4zI3AF/9dGvPOO0EwC8+OB9731w45pb7+iMjPZ2bL3nnnsOO2ilAeZZzRCL QM4CcsDgZlEo58yhdCFnUkvMMQDr16/vdrtheCxnPfGU4087+dgIHHbQvuvuXnvHfQ8VRXt6evqU 15/yO284mYCDDlq5YcPGNbfe2avr0vWBBx546SEHCnMznmNjY6Ojo8w49NBDh4eHTz31VCOsXr2a p2Z6Xzr3y9O9vpRlcp6eqWIszeAsyuyxMI6xaDfkszXxC7sTAgOJSXmX7iGJFARcIIoENP5DMibE SGpw8NRMt1JH0UFssZRF2Z7u9YuyTE4Sip9df8OVP7nOm9084GYxRFMFEIsiOTZt3kIhuFMpvHBk SADLiYHxsaHhoaFSuGCqel0AteHhRx+mIIWEobI4442vLwltylR3S+Cg5QtPOu64uqpYpHa97+EH ayAZUrZOe9SMU0oLxscahnV0WBZOLMhuVZ1ijJ1OOwAMdATtshWKtrH0+/3pmR0RCICQuWaGw7SM UaBCEGDLli3mDvdUd1dMLmYHOwSYXDRR13VVVQDqqicwcbhmFoiQasp1JW5CCMIFk2rqVVU2pUgx suaaYVW/W8aiHQrr95dMTATAFAJMLl6YsvbrJLFYNLmYAFcrCIsmxnv9OrY73TpVKTcv3FThPtTu DHeGckpjo8PMKMvYKsJIp82XXnrpho0PSyzrrDGWzJxSCiG4O1jAoVfVHAOYGJjjHJ4FMcxRkq5G DnaXxqeH3fIZiFB2OiGWzgIOddakavCGOnUmZzbiSy67vNdPRHAzZjZLEoLmDMAURVGAhGOAeTtG 17oMpA5hVN0ZV4NaYBBQ11XS7O6prhdPLByfGHVLcI8hwo0d+++7X5N0YYTtO3YQoA5VBWBZg0gR uKFXGajrGk6hLMwssBDgpuooy6JKtREzcwiBmyXbIUSWs4hortkBAwFFURARMwURTb1IiGQBsKyt Mg6is83MjAlwFZG67jO8VUYAcIdZt+qVnTYHyXB3r7UOgR1uWVVVU26FMhITEAVmaIxfCGc3VYWj EIbDYSJihhDLfp2ZYGYN/9j0pCGzzc3cCORwPumkk1asWFHXdTOu7h5jNDNVZYa7xiKoqru7D3zE zYyfgzdEVSMxTAAaVw45NekLA7cOUVOQCM1kyjmb5bIs3T2wWPOafNDpE044odWKOVvDaTROHQlB TWNAXdeNAnNYXddRGLBIcM3tstUQ9ckUQFEUMUYAhYRt27bt2DkDjhj4eMgJGzdulBAhYoaRkREA MFhWMg8hMHOqaiEENJYmkRvUmjGwbJFJCJZzWZY5Z1WnWSK/sSVFhOAMC7PEWvM+1c1dgzBgyEpA CNwMBHvzFhlA04FAHFiyqRI7kwsjhKrOFISI1L2xFwii2QNHd2eQqzEAt8gQgrsRUSAGIAS3zI2l ad5sPxulMJ9QmvsrxEJMAIN48cTY773zXUPt0usamkPgXm8GpkUUNnPNZGqp1pSJBuVZZMAnEIwc wgrb5ZSc24f7QK+YD1xVzcATYCkRbKgVSXPu9yJBc90uopsJw3N++RGHn/76kxgIgVXVzDRZs1Y1 ezQRYXJoDjEW7ZaBtHlBQFVVRKSErG5AZJpctDgKmVmv6l92xVUK9BIrx8z02OaZn96wppG/KGHl fvsREBitdpFyD5Y9pxgjA26NslFNdasscs6xkMZXSe4wraveUKtslHR2JHMwkUjTf3DI6qruc6EE YJBoNgCYDR4JxM1jcgw5mxo67eHR0VEiSinNdPtTvaoC+o6p6RmDq6qbFSEURZmSAxCJ6sYc+nXF zAQI8UBSzaAZnoIQA82vsKyWLNVMuy0IzwN2w5EvO/S0U1/nuWpFz6nXaRUsqGZmqu4Mqh5Sn1Tr frdp2NxAMDjHmOEZlGC5iaHatQI1dQ+sZR502kFQdXNM75yqZnZY1dP+jPWnPfXLIP1eNzKn3syK 5ZPve+8fuA2yFLI6i0gMmA3qM8BNoRol9Oqq2+85JEjLHOTEQRAlg4rOEAB1nPa6U3OdACSn7154 2d+f+08bNk9t3Nq7/s4H/urvPvvI5k2h1a66vSMOO/TglSvZwICmPpMxOzPXdW3qzAhAYy2lqheF 6n41NyNbRQhA7vdU1YmNkEFOASwGSIjm5CIcaW4qqzrAUrYArpPXDlUNITTrQlVnCsEIYxPjnc5w qmtm7vbr8771rV/c9/Dt9z/4ze9eWCUtQ7SqOmDfA4ZbUUJMCnNiCeomMdamzY628fC2itiOglxr 1XMH3JtfO0UoojB5qnq/jNCExgP91jPetOXJTdf89AaJhRmWL1t21NGv6ndnNFda9UW10ykxa9PU OcUQ65xCiCnXRQgg2V2/YH5ATuM2n1V9RIQjDj+00+nEdsc4tNrtXlX/4Ac/GBsbq/vVcCt+4Oz3 LhwfKggOd/OiCKpuqiEwM+AuRGUUgVuuhjstollz3CEQglmqzXNVVQYEwksPXfWa44696tqfdjrD AF1x1dVXX/vTUMj2HdOxLGKr7E7vHG4Vv336aUVAYHSnq8AUA3LuC5PEgqUJsLd+tyciTRgAcTAA 4MYGEgIRZ01E1CzU7m45gT3Dk+Y5X6hp4kEgCvf7tQISxQFm9lQFISdnDgYQIQS87uSTvnjueRKC M1+/5uc/u+nGwp2JorBWvXYhrz7qldQ4PqVxhVnONciKMgz4Q4Y66rouJcB8qNV2gkMIaOI2qa6Z uSzav5TQNNTykOC973r7ls2b7lq3LqDcb99lb3/zKTmhFSGA+4BAcMC82cikUphgIYQmypho4KWZ S3wbzELANDuHQfSxOQu97rWvPf1UnuPu7nvo8WuuuiL1e57q97znvYcdsn8YJEMReMBCxSLAHXAi YiDXVa675dDwzM4peAKQDcyAqfa67aGWmxWBm54L8HtvPcs0/eiqn5StYSZRs9zTsizVrbdzauHY 6Hvf+Y4jX3YwGQgY7pS97rSnJCHMdPvZOQOkiJHBklISl16vryQJ0AwJUAoppRhZ4KS54YM858BQ Ms11LMTdGzZGchJSckuzKc/ehNhr8nqGApB6rrnpfCC85vhjbl5z451r74YwS1CwCOdUMaw/033z G954wquPcEcaMEK1W90uwtat21O/Z7N8aqaojpxzzrlb9RWDpHqFmFNKydRn+r+cpmk0Q2QsHBn6 k/e/99P/9TPrNz5SVz0ByojgcIAI2dQgPEsBSuP/rxOySrvVZLwR7fIRY5dtYyLSpD2oughrtlbk Rv001nN/ego5p6o+63ff8rrXvDoCmjMFrquqKNrmECEAWT0yOTkTLVm4YL99V7Q6beQFo502AGKY YXLxohcfsB/EUzUyMTpcENQ8MC1Z2P7QB84+4rAXX3n1tY88+vh0r8vMATIx0nnJUS9/8xtOP2i/ pZ4RAnI2BN5///1jawtCNFBZRAaEUSdfvmSREmcjdgy1SwJiQO1YuGB01f77MDNp6pSDqQhP+y5f 7BzhNrlwXOuaQ8nAskVjK5ctzVy4ptHR4YHjG1i2eMHBB+xbFEWq6oUTY0JgwAwTHfpPH/+zb//T BT+76abHn3pKiHLV7xRh2ZIlrz/llBOPP1YMxBCBOhZPThy47zKJcZ/J8cmJkWZFN8eypZMH7r9C RMR10fhIY6U5Y3LxotX7r1B4ITy5YOKXERqyrMQMNxD33e669/6/POdvVh2w+r984qPtxpWnycVB ApKG+BUYuhU4wnHJV75y2plnYqQDIQicGk0zm54CODIxA6zqMsuPW1YOjUGsHMubb7/zL/7jJ09/ 4xnvP/tdAaBcD9yeZpBgzgqwgxnkqFMdi6KX3Brtl6pWEcDSTO5+LxchkDuxGzQGaRhTN4MRB6kM T27dum3L9qmpqeVLly5YMD7UaRcyIJYdUJAaOaFfo4hQoMUIKRMUQfpVLa1OlR2KVknNxjwI9+p+ EVpm7llbraDauA/QS1ZErrKxWrsMyH0JkpIZly6oEoYiBEhJJUpVJ1Vtl7Gu6yKUaOKWmtEVVMnV 6dEnNk9NTQljqFOsXLFcyMktxGgOEBtQp1TGCKDfr8ooURhgBbo1iNCK6M/0hjpFs7ODxF6VmSVE 6nXrVlkU85wqzxWlQm7uZuQGYSPKoJ/dctvll1z6l5/4WHAgZ4TG929MhTWkvmVyRjbM1F/+5H9e uWT5iX98NkYjIoNFB7Eys+wUG+DmAy2Vsw02mTAzZREHX/mTa6+78aYP/emHO2XjQ8wDk2hWaGh3 dl1VIaIAHEWzAZhdDwfHl5gBBuGstchscJcCzEak7kzMgCscLkxmiYUc7uBsYJYmBsCbRtUDOaCe ExXRjIgD5q3a6lmomRUCQHOWGMwMxE6D1C4CNFdFwyeB1chECJDm/iaw35UarzrRIOwEMFUWMTcQ Gw26ZAoRCAyuIGRVkSK5CjWOnAzzgVMtJ4RYJ2/ER9VDk9pqDiYzNM+i6vKMUNvnFJom1rPRAFmz hJDMN2zYsN8+K8qiWby0MWvNwMyDbEs39Gokv+Dff3zq1rVn/sE7h9/9O+gIuFCS5sHEHG6N0hmc JOKg5o3AAJgbMVeatm2dKmNcMDYxeCU0q6aA5wo1n8+VPvPfWWt8fj1z0T/zftwNu6JJnuXdzcYV PU+Xnr+fsy3uquQ5uvHL1vZcFT6jziZZfnYC7Lo4KPWrtD9bhojMbM6ZS0DBtHLFPkUcDLY57do9 A8Ki6k6MQuB5QVEsTHrtV76587IfoW+oXRxwqDUrCsEHPGZj3oMIrvOfOEocnxgdHx0BDJbmPQw/ zyPNMTvP+u+8f3jXZ94zPttQ8ax/7Omf2d6+QJeev5+zLfLTGvq/ru25KnxGnTxXdveLv/Kz7Fbj XMKKiDSKJ8b4zFTLwakRGUI0oKAsZ85DZWh1Z677X1/FtbcgOzICEBkpqcPBIHIzc7XZOS6DHvPg SxFazkGJax5k0+3Fngyef9DVXB5CIzpPO6JmfjKUNpvHMoYYq15/YWh1Nk9des5n8YvbkRO6FRli iERklomcGTTLgTs85WQOAjWxnGTNYo3ZiJy92KPBcxol5wFNPWC2Zr83vzYADZJYmABmkIyNLgoU QmWLETpbnrrwr/8bfnErGEh9ZEN2YvfGHcPeRBMbEceoCgLIIBB25kyiJv4ra+y9+P+PXavaHIM9 tyTNVy2zkmTEGVpHKBSotTM84soRget6USg6T26+4K/OwS9uhzrcQE6N6akGM7i52tyJjAOiymeN tNn49r3Yw8GNCpnTLk2ewFyq5dPuzv0eLMFqJEVWBFk0OWmO7ECIudtfnnh84+aL/9Nf4+qfIfWR ZpAzUkY21IoMchbAshFBgUSwJlmz4Zkaj+xe7NkI89XJ0w7ynH+diOq67m/f8eTatQslToQOOSDS mppuscApA4FC6OdlrfbmLdMXfvozxz7+9oWveCm6CRJn6np7XRXj44sO2J/GRmPgjIGveeB4gDbb /r0ys+fjhU/3nDs7TVVlZ+/687558z9ftLBbL2m3U2/ncIztfi5sEC4TOKZUtYeHtvR2VC3xspU1 zEh8OE0veOnBJ7/nXcuOfrmLmMwmF8w6K5pcSwZk76FGezx+tSNh0c3oM6645rp//Mb0Aw8tiAgp CTM7cvIQCldjIq/rslP2Uj9J2EHFU8IvPf21L/r9s7DvIgRCDANXamPcEEDmgKJJ8Nibnbun44WP T9tt461ADXR7eOKxW77y1Ycu//G+oSySW53K2CLiul8xc1m2d3ZnyqHhR1K/WrX8xHe/bezEo9Ep UAhEcjaRhqmaM4Eb8WkMmvCs/dmLPQe/otB4k7VssD7qrJdeecV5X9MnnhpDLGtvkcDdmPqBd2TN rc7qE45ZffZbsc9ClBHiYFHQ4FQ953kbpVmvduN43atq9mz8Ugc1zr+oqhK4Rh0tswIPP3n/9y67 8wdXjG6bGao9R+dpAAAAtUlEQVS0HaXLvsHS4pcffuJb385HvQIdQpMo7G5E5mBHYJkj5J7Ro3/Z B9yLf3m8wInl2N1b08QKZbhDAaOcSgT0gdvvWffN7z18y2319PbhfSZf8bYzh09+LcYWIDLIsqcQ Y1OdDVLDjSkMiMBdfflXesa9+BfGC5wjjGcTGocjpyABCmRFiKgzegk33/LoA/ftc/rJmBxFCKgD imIX70wEMyMQc25CLHY/cLqpfC+PsOfj/wBU44Dx023p5AAAAABJRU5ErkJggg== --bcaec517cb525013a404ce1c6463-- From Ted.Lemon@nominum.com Fri Nov 9 21:13: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 38B8521F86CD for ; Fri, 9 Nov 2012 21:13:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.441 X-Spam-Level: X-Spam-Status: No, score=-106.441 tagged_above=-999 required=5 tests=[AWL=-0.142, 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 jTkzsHUzqeIP for ; Fri, 9 Nov 2012 21:13:54 -0800 (PST) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id 9785821F8556 for ; Fri, 9 Nov 2012 21:13:54 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKUJ3ikmzIM1lsxmCisMJUH+zM8Y8msj8/@postini.com; Fri, 09 Nov 2012 21:13:54 PST 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 B26AB1B8220 for ; Fri, 9 Nov 2012 21:13:53 -0800 (PST) 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 A5F38190043; Fri, 9 Nov 2012 21:13:53 -0800 (PST) (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, 9 Nov 2012 21:13:53 -0800 From: Ted Lemon To: =?Windows-1252?Q?Ole_Tr=F8an?= Thread-Topic: DHCPv4-over-IPv6 a bad idea? Thread-Index: AQHNvpLypvOqmKsI802XNxNgDTdA+ZficoEAgACazgA= Date: Sat, 10 Nov 2012 05:13:53 +0000 Message-ID: <4CFF5C4F-1001-46EB-8B99-9721C522E072@nominum.com> References: <4B380728-0A9D-4B98-85C8-A723667C2676@nominum.com> <4295AD8A-EA70-4AC7-9096-6EBC5B79FAAD@nominum.com> <78D640BB-6210-4198-B302-DE61731E6D6E@employees.org> In-Reply-To: <78D640BB-6210-4198-B302-DE61731E6D6E@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: <84A647662FFEE14E908A997436F2005B@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: " WG" Subject: Re: [dhcwg] DHCPv4-over-IPv6 a bad idea? X-BeenThere: dhcwg@ietf.org 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, 10 Nov 2012 05:13:55 -0000 On Nov 9, 2012, at 2:59 PM, Ole Tr=F8an wrote: > it is meaningless to have IPv4 configuration information without a networ= k connection that supports transport of IPv4 packets. > use that transport path to run DHCPv4. Yes, of course, the expectation is that after getting the configuration inf= ormation from DHCPv4, the client will somehow use a tunnel to get to what r= emains of the primordial Internet. > didn't you volunteer (:-)) to figure out how to run DHCPv4 on an interfac= e where you have a shared IPv4 address? > (as in port 67/68 isn't available). Yes, we understand how to do this. I am not sure it's documented in a dra= ft yet, but it's certainly an issue that's been talked through and resolved= as part of the lw4over6 effort. From otroan@employees.org Mon Nov 12 01:46: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 CA5C121F854B for ; Mon, 12 Nov 2012 01:46:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.254 X-Spam-Level: X-Spam-Status: No, score=-10.254 tagged_above=-999 required=5 tests=[AWL=0.045, 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 cjOkVlGumrMQ for ; Mon, 12 Nov 2012 01:46:32 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 3C42B21F851F for ; Mon, 12 Nov 2012 01:46:25 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAMXEoFCQ/khN/2dsb2JhbABEw1aBCIIeAQEBAwESAWYQC0ZXBjWHYgabBZ8xkX5hA6RUgWuCcA X-IronPort-AV: E=McAfee;i="5400,1158,6893"; a="78164744" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 12 Nov 2012 09:46:24 +0000 Received: from dhcp-lys01-vla250-10-147-112-82.cisco.com (dhcp-lys01-vla250-10-147-112-82.cisco.com [10.147.112.82]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qAC9kMtN025550 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 12 Nov 2012 09:46:23 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: <4CFF5C4F-1001-46EB-8B99-9721C522E072@nominum.com> Date: Mon, 12 Nov 2012 10:46:21 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4B380728-0A9D-4B98-85C8-A723667C2676@nominum.com> <4295AD8A-EA70-4AC7-9096-6EBC5B79FAAD@nominum.com> <78D640BB-6210-4198-B302-DE61731E6D6E@employees.org> <4CFF5C4F-1001-46EB-8B99-9721C522E072@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1498) Cc: " WG" Subject: Re: [dhcwg] DHCPv4-over-IPv6 a bad idea? X-BeenThere: dhcwg@ietf.org 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, 12 Nov 2012 09:46:32 -0000 Ted, >> didn't you volunteer (:-)) to figure out how to run DHCPv4 on an = interface where you have a shared IPv4 address? >> (as in port 67/68 isn't available). >=20 > Yes, we understand how to do this. I am not sure it's documented in = a draft yet, but it's certainly an issue that's been talked through and = resolved as part of the lw4over6 effort. I think Suresh was also talking about writing this up. would you be able to share what the ideas are for how to do this? cheers, Ole From Ted.Lemon@nominum.com Mon Nov 12 04:43: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 CCDFD21F8597 for ; Mon, 12 Nov 2012 04:43:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.434 X-Spam-Level: X-Spam-Status: No, score=-106.434 tagged_above=-999 required=5 tests=[AWL=-0.135, 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 Dw2ZwTyoT1DO for ; Mon, 12 Nov 2012 04:43:09 -0800 (PST) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id ECBA021F8596 for ; Mon, 12 Nov 2012 04:43:08 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKUKDu3N6l+HHIvTSESmtNwC/ZwoTUPBtE@postini.com; Mon, 12 Nov 2012 04:43:09 PST 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 197B51B80C3 for ; Mon, 12 Nov 2012 04:43:08 -0800 (PST) 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 086FB190043; Mon, 12 Nov 2012 04:43:08 -0800 (PST) (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, 12 Nov 2012 04:43:01 -0800 From: Ted Lemon To: =?Windows-1252?Q?Ole_Tr=F8an?= Thread-Topic: DHCPv4-over-IPv6 a bad idea? Thread-Index: AQHNvpLypvOqmKsI802XNxNgDTdA+ZficoEAgACazgCAA3DLgIAAMVyA Date: Mon, 12 Nov 2012 12:43:01 +0000 Message-ID: References: <4B380728-0A9D-4B98-85C8-A723667C2676@nominum.com> <4295AD8A-EA70-4AC7-9096-6EBC5B79FAAD@nominum.com> <78D640BB-6210-4198-B302-DE61731E6D6E@employees.org> <4CFF5C4F-1001-46EB-8B99-9721C522E072@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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: " WG" Subject: Re: [dhcwg] DHCPv4-over-IPv6 a bad idea? X-BeenThere: dhcwg@ietf.org 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, 12 Nov 2012 12:43:10 -0000 On Nov 12, 2012, at 3:46 AM, Ole Tr=F8an wrote: > would you be able to share what the ideas are for how to do this? There are two basic options. We speak of the CRA and the DHCP client as s= eparate entities, but in fact there is no reason to separate them=97the DHC= P client could simply send a relay-wrapped packet over IPv6 directly. So = that's the simpler solution. The other solution, if you want to keep the C= RA and the DHCP client isolated, is to simply always broadcast, and have th= e client use a zero source address. In this way, we are not using the sha= red IP address for DHCPv4 at all. From otroan@employees.org Mon Nov 12 04:47: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 53BBD21F84C7 for ; Mon, 12 Nov 2012 04:47:29 -0800 (PST) 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 0SWqbrhal-iP for ; Mon, 12 Nov 2012 04:47:28 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 8296A21F84C4 for ; Mon, 12 Nov 2012 04:47:28 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAEPuoFCQ/khM/2dsb2JhbABEwBWDQoEIgh4BAQEDARIBZhALRlcGLgeHYgaacZ9HkX5hA6RUgWuCcA X-IronPort-AV: E=McAfee;i="5400,1158,6893"; a="78168714" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 12 Nov 2012 12:47:27 +0000 Received: from dhcp-lys01-vla250-10-147-112-82.cisco.com (dhcp-lys01-vla250-10-147-112-82.cisco.com [10.147.112.82]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qACClQG6000364 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 12 Nov 2012 12:47:27 GMT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: =?windows-1252?Q?Ole_Tr=F8an?= In-Reply-To: Date: Mon, 12 Nov 2012 13:47:26 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6C1DB917-2C49-4839-9541-3FA38FF6A401@employees.org> References: <4B380728-0A9D-4B98-85C8-A723667C2676@nominum.com> <4295AD8A-EA70-4AC7-9096-6EBC5B79FAAD@nominum.com> <78D640BB-6210-4198-B302-DE61731E6D6E@employees.org> <4CFF5C4F-1001-46EB-8B99-9721C522E072@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1499) Cc: " WG" Subject: Re: [dhcwg] DHCPv4-over-IPv6 a bad idea? X-BeenThere: dhcwg@ietf.org 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, 12 Nov 2012 12:47:29 -0000 Ted, >> would you be able to share what the ideas are for how to do this? >=20 > There are two basic options. We speak of the CRA and the DHCP client = as separate entities, but in fact there is no reason to separate = them=97the DHCP client could simply send a relay-wrapped packet over = IPv6 directly. So that's the simpler solution. The other solution, if = you want to keep the CRA and the DHCP client isolated, is to simply = always broadcast, and have the client use a zero source address. In = this way, we are not using the shared IP address for DHCPv4 at all. good point, using the unspecified address (0.0.0.0) sending to = 255.255.255.255 should work fine on a point to point tunnel. for this to work for MAP, we'd need to specify that the tunnel to the = default (BR) is a p2p tunnel as opposed to a special node on the NBMA = link. if DHCP was only used for other configuration information (DHCPINFORM), = would existing clients still use the unspecified address or would the = use a global address if available? cheers, Ole= From joelja@bogus.com Tue Nov 13 22:49: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 8E79221F8475; Tue, 13 Nov 2012 22:49:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 z3xabzp+V4cU; Tue, 13 Nov 2012 22:49:35 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id BC2AF21F87A6; Tue, 13 Nov 2012 22:49:34 -0800 (PST) Received: from joels-MacBook-Air.local (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id qAE6nUbG049549 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 14 Nov 2012 06:49:32 GMT (envelope-from joelja@bogus.com) Message-ID: <50A33EFA.7070008@bogus.com> Date: Tue, 13 Nov 2012 22:49:30 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: draft-ietf-dhc-addr-registration@tools.ietf.org, IPv6 Ops WG , dhcwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Wed, 14 Nov 2012 06:49:32 +0000 (UTC) X-Mailman-Approved-At: Wed, 14 Nov 2012 07:15:27 -0800 Subject: [dhcwg] some feedback on http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-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, 14 Nov 2012 06:49:35 -0000 I took a look at this draft since it was also presented in v6ops... http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-01 There's a couple issues that are quite striking. I kind of concur with Fred Baker that the most appropiate method for tracking l2/l3 binding for address identification is probably more akin to syslog. That is, since you don't really trust the hosts, having a switch/router, simply sysloging all new NDP cache entries pretty much achives the same thing execept with a lot less signaling. If a strong assertion of L2 identity in support of l2/l3 bindings is required 802.1x or the wireless equivalanet seems appropiate, e.g. it's what we do today. Availing oneself of a dhcp/ra option entails a lot of signaling for what is likely a relatively ephemeral port (windows machines and macs registering privacy addresses for example). specifiying a binding lifetime seems of limited utility since the host will probably discard the address long before the lifetime expires if it's sufficently long enough to allow for long lived connections using that address. From Ted.Lemon@nominum.com Wed Nov 14 07:20: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 E62F421F844E for ; Wed, 14 Nov 2012 07:20:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.578 X-Spam-Level: X-Spam-Status: No, score=-106.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 97RNxRejYMCB for ; Wed, 14 Nov 2012 07:20:18 -0800 (PST) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 2B02721F8444 for ; Wed, 14 Nov 2012 07:20:18 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKUKO2rOQl3PrL2icfyUqK1JJC3qFK/WV2@postini.com; Wed, 14 Nov 2012 07:20:18 PST 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 4C1391B80B0 for ; Wed, 14 Nov 2012 07:20:12 -0800 (PST) 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 435AF190043 for ; Wed, 14 Nov 2012 07:20:12 -0800 (PST) (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.0318.004; Wed, 14 Nov 2012 07:20:12 -0800 From: Ted Lemon To: " WG" Thread-Topic: WGLC: draft-ietf-dhc-dhcpv6-radius-opt-04 Thread-Index: AQHNwnuJXxc1SNgKKEqdICsCoFzJ1Q== Date: Wed, 14 Nov 2012 15:20:11 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630747405925@mbx-01.win.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: <2C6782AA09DCDA4F8673B4FF2CF38C5A@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-radius-opt-04 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 15:20:20 -0000 The authors of this document have requested a working group last call. Th= e document describes a mechanism, similar to the mechanism in DHCPv4, for c= arrying RADIUS options in DHCP packets. If this is of interest to you, pl= ease review the draft: http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-radius-opt-04 If you have comments, please send them to the working group mailing list. = If you are in favor of advancing the document as it is, please reply to th= is message and say so. If you do not favor advancing the document, and do= not have specific comments, please reply to this message indicating that y= ou don't favor advancing the document. Since the document has my name on it, John will be doing the evaluation of = consensus. He will do this on or after November 28. Thanks! From ek@google.com Wed Nov 14 19:24: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 BE8F821F8514 for ; Wed, 14 Nov 2012 19:24:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TThe8t8D67Ua for ; Wed, 14 Nov 2012 19:24:39 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 461FA21F8513 for ; Wed, 14 Nov 2012 19:24:39 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so1290035oag.31 for ; Wed, 14 Nov 2012 19:24:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=nyVktyWmlsf3w8wep/2iNfvobyESXJxfdK/Z2+NPMZ8=; b=j+/uzyTfSQZ4iUE8+QDKL7lyYynaU4IwUFjSoshum0y2Hzg0cfMJfkdZMFDLB7Ntlm Li6CK+VmDVm2FJOJeJCQV/Z7rf5miE2p6L5slAwjhE+MyXYultGvzk8H2bzbz5X5hkUR fLOZcR2pnnYy3pLupWbJ9IucWdfHjJlML+8wwtf6k0eA6O+0LM0bnfyZ6qTP0rVW3QH7 eKT8kO8lvg6q8OB4byCprKL5aKWLjg94Pe9Y3+lXrKewRfRkvDkeQW2VlGxB+edumCUP 78oiAwiCyZtTlKaOjpLqbB9tQ3OKSsNFt4jqnyU9ptkLFnx5sR1IQwEOfNbNhAOOMg5n jZwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=nyVktyWmlsf3w8wep/2iNfvobyESXJxfdK/Z2+NPMZ8=; b=G/XBYc++eBRKrVzfMX+KDpdSuoCkqnXqdoelQcyDuXzC9obcbSskAz4qLTeeq8qgX6 0yG9Yr3Y+rhH9efx6ETa527J5kygDdNXSSRqK3S2ETmL2w7l/DgpZtArf+yFWkXXUXKR i7/rfNJLAejFSVHJoydgkrwrxSvMh4+rK/2sDHNxz7b3tkQ1obTY5v4aXoJBsTJeTkjZ xNOgRpn+B86MCRhOv8mp/3lMl8m+VEMpn9rHBBcqE60sG+hResG/yRwHrv3bw+wAXLl+ AxSJwDvwXJcCeMEDIB2ZCEd8hYxpIcXbTQS69/RvQ+JbnKgWq3Zhur/NmuvDfxrZlrNR GH8g== Received: by 10.182.177.100 with SMTP id cp4mr23244069obc.71.1352949878402; Wed, 14 Nov 2012 19:24:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.4.210 with HTTP; Wed, 14 Nov 2012 19:24:18 -0800 (PST) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E947B0E73@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E947B0E73@PUEXCB1B.nanterre.francetelecom.fr> From: Erik Kline Date: Wed, 14 Nov 2012 19:24:18 -0800 Message-ID: To: mohamed.boucadair@orange.com Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQnbH4yUkfWUK7ReBgC9ddU4HcKI8fQelyux60c7Gietm+Yz99CqWlK20O2r5Sp4eihGnfdzda9kYxUdS3TY4upnFiCAwUqyGFb7sNe2i2hoP0Ww/Sg3A8dxp7RDnk6GD9FkScJo065S0lMQIpG0fvTewUPREaz4/+IQxTIMbCDhjosc3QlZ6UFS89cK7DB5y+IkJCy4 Cc: "" Subject: Re: [dhcwg] IP address vs. FQDN discussion X-BeenThere: dhcwg@ietf.org 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, 15 Nov 2012 03:24:39 -0000 After a very cursory reading, I would say largely +1. I'm in favour of something like "a UTF-8 string intended to passed to a higher layer address resolution mechanism, a la getaddrinfo(), et cetera". On 8 November 2012 07:30, wrote: > Dear all, > > As this question is repeatedly raised, including in the ongoing dhc meeting, > we have edited a draft which proposes an approach which conciliates both > modes: It defines a name option encoded as UTF-8 string which can be a > domain name, IPv4 address literals, etc. The draft is available at: > > http://tools.ietf.org/html/draft-boucadair-dhc-address-name-encoding-01 > > Comments are welcome. > > Cheers, > Med > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > From ghalwasi@cisco.com Wed Nov 14 20:26: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 1150821E8047 for ; Wed, 14 Nov 2012 20:26:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Ec0IL5cc10X for ; Wed, 14 Nov 2012 20:26:36 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 519B821E8039 for ; Wed, 14 Nov 2012 20:26:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1329; q=dns/txt; s=iport; t=1352953596; x=1354163196; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=b1BAoWtp7LkZorOHv8jDhNtaa8q9znJypi4QuVXniyA=; b=gll2ujIy+WiRi1cQOLmgmjQKZ407MM0wL0kb1MlHSaX2hw/PVEKWqRDf 7WjYQ269q6RrsExniNI0uf+qVGQkf17GDHxlfcylB8WVr6LcFJVJ09x/k Um7z5plHDaphlWF+kPbbuiEdV62I2V98rNGlTAD6F5+T9GiCnQPP9+WKX A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJNupFCtJV2Z/2dsb2JhbABEw0eBCIIeAQEBBAEBAQ8BJzQXBAIBCBEEAQELFAkHJwsUCQgCBAESCBqHaQubWqALjC2FS2EDlxiNPIFrgm+CGQ X-IronPort-AV: E=McAfee;i="5400,1158,6896"; a="142596748" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP; 15 Nov 2012 04:26:36 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qAF4QZIc019863 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 15 Nov 2012 04:26:35 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.220]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.001; Wed, 14 Nov 2012 22:26:35 -0600 From: "Gaurav Halwasia (ghalwasi)" To: Ted Lemon , " WG" Thread-Topic: WGLC: draft-ietf-dhc-dhcpv6-radius-opt-04 Thread-Index: AQHNwnuJXxc1SNgKKEqdICsCoFzJ1ZfqTZWg Date: Thu, 15 Nov 2012 04:26:34 +0000 Message-ID: <90903C21C73202418A48BFBE80AEE5EB1BDD0C40@xmb-aln-x06.cisco.com> References: <8D23D4052ABE7A4490E77B1A012B630747405925@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630747405925@mbx-01.win.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.142.100.91] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19364.000 x-tm-as-result: No--35.644800-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] WGLC: draft-ietf-dhc-dhcpv6-radius-opt-04 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 04:26:37 -0000 I have read and reviewed this draft and I support this work and want this d= ocument to move forward. Thanks, Gaurav -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= ed Lemon Sent: Wednesday, November 14, 2012 8:50 PM To: WG Subject: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-radius-opt-04 The authors of this document have requested a working group last call. Th= e document describes a mechanism, similar to the mechanism in DHCPv4, for c= arrying RADIUS options in DHCP packets. If this is of interest to you, pl= ease review the draft: http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-radius-opt-04 If you have comments, please send them to the working group mailing list. = If you are in favor of advancing the document as it is, please reply to th= is message and say so. If you do not favor advancing the document, and do= not have specific comments, please reply to this message indicating that y= ou don't favor advancing the document. Since the document has my name on it, John will be doing the evaluation of = consensus. He will do this on or after November 28. Thanks! _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From roberta.maglione@telecomitalia.it Thu Nov 15 02:05: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 9002521F854E for ; Thu, 15 Nov 2012 02:05:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.457 X-Spam-Level: X-Spam-Status: No, score=-0.457 tagged_above=-999 required=5 tests=[AWL=-0.227, BAYES_05=-1.11, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, 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 8UrYpfbdxNOp for ; Thu, 15 Nov 2012 02:05:46 -0800 (PST) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by ietfa.amsl.com (Postfix) with ESMTP id 6611221F8549 for ; Thu, 15 Nov 2012 02:05:46 -0800 (PST) Received: from GRFHUB702BA020.griffon.local (10.188.101.112) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.3.279.5; Thu, 15 Nov 2012 11:05:42 +0100 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by GRFHUB702BA020.griffon.local ([10.188.101.112]) with mapi; Thu, 15 Nov 2012 11:05:41 +0100 From: Maglione Roberta To: 'Ted Lemon' , " WG" Date: Thu, 15 Nov 2012 11:05:41 +0100 Thread-Topic: WGLC: draft-ietf-dhc-dhcpv6-radius-opt-04 Thread-Index: AQHNwnuJXxc1SNgKKEqdICsCoFzJ1Zfqqxqw Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE519AC44BE1@GRFMBX704BA020.griffon.local> References: <8D23D4052ABE7A4490E77B1A012B630747405925@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630747405925@mbx-01.win.nominum.com> Accept-Language: en-US, it-IT Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, it-IT x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-radius-opt-04 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 10:05:47 -0000 Hello, I have read the draft and I support this work. I have a comment: Section 4 says: " The RADIUS attributes listed in the below table are recom= mended as the first batch of attributes in the IANA Registry of 'RADIUS Attributes Permitted in the DHCPv6 RADIUS option'" I would suggest adding at the end "additional attributes may be added to this list in future according to new= RADIUS attributes specifications" A part from that I am in favor of advancing this draft. Regards Roberta -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= ed Lemon Sent: Wednesday, November 14, 2012 4:20 PM To: WG Subject: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-radius-opt-04 The authors of this document have requested a working group last call. Th= e document describes a mechanism, similar to the mechanism in DHCPv4, for c= arrying RADIUS options in DHCP packets. If this is of interest to you, pl= ease review the draft: http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-radius-opt-04 If you have comments, please send them to the working group mailing list. = If you are in favor of advancing the document as it is, please reply to th= is message and say so. If you do not favor advancing the document, and do= not have specific comments, please reply to this message indicating that y= ou don't favor advancing the document. Since the document has my name on it, John will be doing the evaluation of = consensus. He will do this on or after November 28. Thanks! _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. From asang.et@gmail.com Thu Nov 15 03:10: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 AD5D521F846E for ; Thu, 15 Nov 2012 03:10:31 -0800 (PST) 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 UO0hbdUef-4f for ; Thu, 15 Nov 2012 03:10:27 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 040EF21F8451 for ; Thu, 15 Nov 2012 03:10:26 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id uo1so1091061pbc.31 for ; Thu, 15 Nov 2012 03:10:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; bh=y8HCSo6Ncg5pNvvSAwslDo9cSMqgkyOx4MBdxhCNZvU=; b=pnHWrez4AXwOc3y1YBAMC22k7dGZDc6mRlzj57Mii+iQEdYHD8g6zqzZSZd+Mq5Ux5 LUhtu9bSkTFyPVcKriyjaFsbw3V73wZgapEGO47GHy3nixTGK5mUuFfvv9LDDx5eUKl+ AKonWXMNETfl2GwRpqiIbitYp9Ug4suif7cAJEUz9CSZRW27yWeayLKxCVmkxFWQcNAv 9Gj8PQr/vPR/YSymjD5K+YlWZiqWwwdgu57/zJNMhzhvp1ELVoHmvq2vDtEAZ4+wjo4T I2WRMaAsSqUXvHtovu7yOCoFP0BDGEckdeqP/TDatfoqnnpuwSmK1OCFm41zgvXcFg6n HJTQ== Received: by 10.66.72.136 with SMTP id d8mr2425587pav.4.1352977826798; Thu, 15 Nov 2012 03:10:26 -0800 (PST) Received: from ETPC ([50.117.120.74]) by mx.google.com with ESMTPS id iu8sm9356349pbc.71.2012.11.15.03.10.24 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 15 Nov 2012 03:10:25 -0800 (PST) From: "Ehsan T." To: "'Ted Lemon'" , References: <4B380728-0A9D-4B98-85C8-A723667C2676@nominum.com> <4E9AA0D4-5135-4464-913E-7B8D0B0737B2@nominum.com> In-Reply-To: <4E9AA0D4-5135-4464-913E-7B8D0B0737B2@nominum.com> Date: Thu, 15 Nov 2012 19:10:21 +0800 Message-ID: <50a4cda1.88c5440a.5218.fffff1dc@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: AQHNrTmjFOygSqT8jUKurJPUyMWVCpfglOQAgApQTRA= Content-Language: en-us 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, 15 Nov 2012 11:10:31 -0000 Hi There! I do agree with continuing it. ----------------------- Yours Sincerely, Ehsan Taghizadeh -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Ted Lemon Sent: Thursday, November 08, 2012 9:26 PM To: WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv4-over-ipv6 On Oct 18, 2012, at 10:05 AM, Ted Lemon wrote: > 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. > > We will evaluate consensus on November 1. There was one response in favor of this WGLC. The document got substantial support in the previous WGLC in June. Has that support gone away, or did people just not respond because they responded to the previous WGLC? If you want this document to advance, please do respond to the WGLC. Thanks! _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From mohamed.boucadair@orange.com Thu Nov 15 07:04: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 712AC21F850D for ; Thu, 15 Nov 2012 07:04:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[AWL=0.336, 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 I344COKrJMg0 for ; Thu, 15 Nov 2012 07:04:04 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 93FBF21F8930 for ; Thu, 15 Nov 2012 07:04:04 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id BF6A52DC434; Thu, 15 Nov 2012 16:04:03 +0100 (CET) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id A4EB727C053; Thu, 15 Nov 2012 16:04:03 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Thu, 15 Nov 2012 16:04:03 +0100 From: To: Erik Kline Date: Thu, 15 Nov 2012 16:04:01 +0100 Thread-Topic: [dhcwg] IP address vs. FQDN discussion Thread-Index: Ac3C4MAM+e9OsjAUT6Wp6HCzcayFAwAYSaGQ Message-ID: <94C682931C08B048B7A8645303FDC9F36E95C9F87B@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E947B0E73@PUEXCB1B.nanterre.francetelecom.fr> 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.11.15.142418 Cc: "" Subject: Re: [dhcwg] IP address vs. FQDN discussion X-BeenThere: dhcwg@ietf.org 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, 15 Nov 2012 15:04:05 -0000 Dear Erik, Thanks for reading the draft and also for supporting this proposal.=20 For information, I have submitted an updated version of the draft which is = available at: http://tools.ietf.org/html/draft-boucadair-dhc-address-name-encoding-02 Comments from WG are more than welcome. Cheers, Med=20 >-----Message d'origine----- >De : Erik Kline [mailto:ek@google.com]=20 >Envoy=E9 : jeudi 15 novembre 2012 04:24 >=C0 : BOUCADAIR Mohamed OLNC/OLN >Cc : >Objet : Re: [dhcwg] IP address vs. FQDN discussion > >After a very cursory reading, I would say largely +1. I'm in favour >of something like "a UTF-8 string intended to passed to a higher layer >address resolution mechanism, a la getaddrinfo(), et cetera". > >On 8 November 2012 07:30, wrote: >> Dear all, >> >> As this question is repeatedly raised, including in the=20 >ongoing dhc meeting, >> we have edited a draft which proposes an approach which=20 >conciliates both >> modes: It defines a name option encoded as UTF-8 string=20 >which can be a >> domain name, IPv4 address literals, etc. The draft is available at: >> >>=20 >http://tools.ietf.org/html/draft-boucadair-dhc-address-name-encoding-01 >> >> Comments are welcome. >> >> Cheers, >> Med >> >> >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg >> >= From kcd@chrysler.com Thu Nov 15 14:32: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 8245121F876A for ; Thu, 15 Nov 2012 14:32:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h5SfWRkrlBK6 for ; Thu, 15 Nov 2012 14:32:36 -0800 (PST) Received: from shbmap01.extra.chrysler.com (shbmap01.out.extra.chrysler.com [129.9.168.35]) by ietfa.amsl.com (Postfix) with ESMTP id C549321F8769 for ; Thu, 15 Nov 2012 14:32:34 -0800 (PST) Received: from odbmap04.oddc.chrysler.com (Unknown_Domain [53.28.32.58]) by shbmap01.extra.chrysler.com (Symantec Messaging Gateway) with SMTP id FF.8A.02915.28D65A05; Thu, 15 Nov 2012 17:32:34 -0500 (EST) X-AuditID: 8109a822-b7f566d000000b63-32-50a56d823e72 Received: from shmsp070.shdc.chrysler.com (shmsp070.shdc.chrysler.com [53.231.161.247]) by odbmap04.oddc.chrysler.com (Symantec Messaging Gateway) with SMTP id 2F.A1.02648.18D65A05; Thu, 15 Nov 2012 17:32:33 -0500 (EST) Received: from [10.143.0.242] (CITMNCNU1410TPT.cg.chrysler.com [10.143.0.242]) by shmsp070.shdc.chrysler.com (8.13.8+Sun/8.13.8/chrysler-relay-1.4-kcd) with ESMTP id qAFMWXIa013469 for ; Thu, 15 Nov 2012 17:32:33 -0500 (EST) Message-ID: <50A56D7C.1030504@chrysler.com> Date: Thu, 15 Nov 2012 17:32:28 -0500 From: Kevin Darcy User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: dhcwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA11Ta0gUURjl7q67o3l1HHW9ro9s0CDFTdHQXmpUEESxUD9Ces2uozPsrG4z s6W/sheU/ehhD1yEylbyFaVISgbaVkTviIU0K+hhgmX0wl4UzR13dbZ/3z3n++75zrlcQk+d ISwEXy2zYjUj0MYow6LUjCW5e12ttryvXbriFwf3gzKwxuf7qbOB8qhlFazA72TFhSXbo7iR viMG9++42pHRUVAPBmMaQCSByELU9OkNmK7N6PHLS0ZcU+QjgDoaihoAofbcC5Q1gCgFfgFQ /4ke0/ThG0C3Dt6IwAOQzEGBveMmXBvILNT1uVGPayOZia4+u6DiiWQ58ndfN033x6E7TW8N uE4gKdR7+6MO1/FkAbrqfW3AwnpyKZoaEDGsJ+eivslmPdZF5GETGnu4T3cUkF7NVd7ZEa9m 5CzQd4AUibO7GHdevpWtlUXG6uDEOklgRaujxtUDlBj3RLbR/eCOF/qBk9DRifBiZauNirHX VNRxjMRtEz0CK9EJcIegwHAGtnsEJ22BJRiNn0Gr2V3K5bLySHQ6vNfts1FJM5zkkdy8g6/x SNs8ouAHKYSBToK/z2y2UWQVI7NOlnWz4rSeH+wiCBrBcnx9nMhWsbWVvCCHaGVuK68wpJZR N0qDQ78UVbOW0Cw1D5bFtNgoi5b+fy8dEekHVUS04nmd6llyMy6JrwpKx8M2p4JGh1BVNhm+ wq1UCNRIpkF7D94oRIXL3QV1liTowMMk7uA81TMuLWbYyZ+3UbEaAqtZUuFqTsETNfisoCUD WjGbrGHDNdXPM37u+wRwEEDxU4DVo5WvNWuSgpexyTlBUPWI4FP1NYKYxmIqLFT3CTLhahNK ljoly95UH85SZmRtlpknW3CWQTSYZfqpFpxlEAzLcj7uN4eocCVLPdCZrx3vHssvdt5kTlfc H451DF95melavxs5Jle+rmnKWX5sw+jP0hT7sfeduQ+O9CxA/X+si/h2+cA+t+1v49qT2Vl9 1stf0jb6Rjg5whixSfgQGzjcXMItPz1kFBGzZXFpUe+hyVWBwRXP248mutzE1PMA+yTQ9yPp Rt6A6d0B2iBxTH62XpSYf+lHe0ayBAAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrCIsWRmVeSWpSXmKPExsVi+nzhd93G3KUBBlOfWFjc7WhhdGD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxs3t/SwFvwUrbt6+zdjAuJ+vi5GDQ0LAROL0FYcuRk4gU0zi wr31bF2MXBxCAncZJXZM2cQO4XxhlDjacZgVpIpXQFviStNzdhCbRUBVYs3HycwgNpuAisSu W8vB4qICURKHNh5kh6gXlDg58wkLiC0iICSx5fg7JhBbWMBYYtesRywgRzALWEt8210EEmYW kJfY/nYO8wRG3llIumchVM1CUrWAkXkVo1R+SlJuYoGBiV5+SkqyXnJGUWVxTmqRXnJ+7iZG UADJKFjuYJx7Q/4QowAHoxIP7/70pQFCrIllxZW5hxglOZiURHnXpgGF+JLyUyozEosz4otK c1KLDzFKcDArifB6ygHleFMSK6tSi/JhUtIcLErivEIWQCmB9MSS1OzU1ILUIpisDAeHkgSv Yg5QVrAoNT21Ii0zpwQhzcTBCTKcB2h4F0gNb3FBYm5xZjpE/hSjLsecme1PGIVY8vLzUqXE eaVBigRAijJK8+DmwCL/FaM40FvCvMYgVTzApAE36RXQEiagJVtkloAsKUlESEk1MO69f+HU qxsvJ5xZbZ3y5/3OIys8v3udSysT9HFs4jVymxH6dNvbpFfMjqlhRwTuyEsznOHWqp4r1lAk +31n6bdtOtcjvXJV/PS1ngR/0rh1bVZMU+K/DTsc227EmzwvP/FeND12nt6yR0+kCiUfMix6 694+Jcw3OEB1l+8u+8CHOS6M0xQ+n1JiKc5INNRiLipOBAB60X0t1wIAAA== Subject: [dhcwg] Unnecessary SSO Strictness on DHCPRELEASE? X-BeenThere: dhcwg@ietf.org 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, 15 Nov 2012 22:32:36 -0000 (First time posting to this list, please bear with me on any etiquette faux pas). Is the following text from Section 2 of RFC 3011 (Subnet Selection Option, aka "SSO") to be interpreted as a MUST NOT: "This option does not require changes to operations or features of the DHCP server other than to select the subnet on which to allocate an address." as in: "DHCP server implementations MUST NOT behave differently depending on the presence, absence or contents of an SSO, for DHCP transactions NOT involving allocation of an address"? The reason I ask is because a popular DHCP server implementation performs a "subnet validity check" as a precondition to processing a DHCPRELEASE packet, and this "subnet validity check" will yield different results, depending on SSO in the DHCPRELEASE packet. Couple that with a client implementation that doesn't consistently send SSO on its DHCPRELEASEs, even when SSO was used for the initial address allocation. The end result is that DHCPRELEASEs fail, causing inefficient dynamic scope utilization. I could, of course, humor the "subnet validity check" code by defining dummy "internal" (in the SSO nomenclature) scopes, but it sticks in my craw that I would have to define unnecessary and unused DHCP scopes in order for DHCPRELEASEs to work as expected. Rather than an ugly "dummy scope" workaround, I'd prefer to swing the standards-compliance cluebat in one of two directions: 1) at the client implementor, for not consistently including SSO on DHCPRELEASEs, i.e. failing to be "conservative in what it sends" (although absence of any mention of DHCPRELEASE in RFC 3011 makes this a somewhat weak argument), or 2) at the server implementor, for being overly strict (perhaps accidentally) with its "subnet validity check", i.e. failing to be "liberal in what it accepts" Opinions? - Kevin P.S. I hope to replace the use of SSO with VSSO in our next refresh of client software, but RFC 6607 apparently doesn't discuss DHCPRELEASE either. If anyone is considering -bis versions of either SSO and/or VSSO, could we please clarify DHCPRELEASE behavior? P.P.S. I did search the list archives with several search terms, but did not find any previous discussion on this topic. From iesg-secretary@ietf.org Thu Nov 15 14:45: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 8F8D121F8A3D; Thu, 15 Nov 2012 14:45:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 K4fZoEFUXs8E; Thu, 15 Nov 2012 14:45:12 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9408E21F8A87; Thu, 15 Nov 2012 14:45:11 -0800 (PST) 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.36 Message-ID: <20121115224511.23302.94529.idtracker@ietfa.amsl.com> Date: Thu, 15 Nov 2012 14:45:11 -0800 Cc: dhc mailing list , dhc chair , RFC Editor Subject: [dhcwg] Protocol Action: 'Client Identifier Option in DHCP Server Replies' to Proposed Standard (draft-ietf-dhc-client-id-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: Thu, 15 Nov 2012 22:45:13 -0000 The IESG has approved the following document: - 'Client Identifier Option in DHCP Server Replies' (draft-ietf-dhc-client-id-07.txt) as Proposed Standard This document is the product of the Dynamic Host Configuration Working Group. The IESG contact persons are Ralph Droms and Brian Haberman. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-dhc-client-id/ Technical Summary: This document updates RFC2131 to change the DHCP server's behavior with respect to the DHCP client identifier option. Prior to this update, DHCP servers were expected not to return the client identifier to the client in DHCPOFFER, DHCPACK and DHCPNAK messages. Following this update, DHCP servers are expected to return the client identifier in all three of these messages. This resolves a problem where in cases where the chaddr field of the client identifier is zero, the client can't accurately identify DHCP messages as being directed specifically to it. Working Group Summary: There was essentially unanimous support for this document, and the document received wide review. Document Quality: This is a relatively minor change to the existing DHCPv4 protocol, and is not expected to create interoperability problems. The authors have done a test implementation with a Cisco DHCP server, and tested this against five DHCP clients, and no problems were observed. It's always possible that some client somewhere will break, but these results are encouraging. Personnel: Ted Lemon is the Document Shepherd. Ralph Droms is the responsible Area Director. From Ted.Lemon@nominum.com Thu Nov 15 14:54: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 30FC811E8097 for ; Thu, 15 Nov 2012 14:54:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.579 X-Spam-Level: X-Spam-Status: No, score=-106.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 PQRHlq27oTWG for ; Thu, 15 Nov 2012 14:54:50 -0800 (PST) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id 75F7521F872D for ; Thu, 15 Nov 2012 14:54:50 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKUKVyuo02/5y9Yz8rVN9yWgMPpcBI3pTm@postini.com; Thu, 15 Nov 2012 14:54:50 PST 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 9CD5FF8004 for ; Thu, 15 Nov 2012 14:54:49 -0800 (PST) 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 93DA4190043; Thu, 15 Nov 2012 14:54:49 -0800 (PST) (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.0318.004; Thu, 15 Nov 2012 14:54:49 -0800 From: Ted Lemon To: Kevin Darcy Thread-Topic: [dhcwg] Unnecessary SSO Strictness on DHCPRELEASE? Thread-Index: AQHNw4EfFr4AGQD00UuKu2UQDuTZAZfsB4YA Date: Thu, 15 Nov 2012 22:54:49 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630747406804@mbx-01.win.nominum.com> References: <50A56D7C.1030504@chrysler.com> In-Reply-To: <50A56D7C.1030504@chrysler.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: <5AD01856851ED64EB2930D9B7111177A@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [dhcwg] Unnecessary SSO Strictness on DHCPRELEASE? X-BeenThere: dhcwg@ietf.org 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, 15 Nov 2012 22:54:51 -0000 On Nov 15, 2012, at 5:32 PM, Kevin Darcy wrote: > "This option does not require changes to operations or features of the DH= CP server other than to select the subnet on which to allocate an address." >=20 > as in: "DHCP server implementations MUST NOT behave differently depending= on the presence, absence or contents of an SSO, for DHCP transactions NOT = involving allocation of an address"? No, the first sentence would translate, in the way you have proposed, to th= is: > as in: "DHCP server implementations MAY behave differently depending on t= he presence, absence or contents of an SSO, for DHCP transactions NOT invol= ving allocation of an address"? IOW, "does not require" is not synonymous with "requires that there be no." In this case, I would say that the client is most broken=97it should send a= n SSO consistently with every message, not just with initial messages. Th= e server is slightly broken=97I'm pretty sure there's nothing in the RFC th= at allows it to disregard a DHCPRELEASE simply because it doesn't contain a= n SSO. The document is fairly broken. If you wanted to update it to explicitly r= equire that the client send an SSO in every packet relating to the lease wi= th which it first sent the SSO, I would support that effort. =20 I think that would be a better fix than requiring that the server not behav= e the way your server does=97the behavior you're seeing in the server is mo= re like a non sequitur than a failure to accurately follow the spec. But = it's probably there because the server implementor either had to deal with = or expected to have to deal with DoS attacks from off-network. From Stephen.Jacob@nominum.com Thu Nov 15 15:40: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 B5A031F041A for ; Thu, 15 Nov 2012 15:40:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, J_CHICKENPOX_61=0.6, J_CHICKENPOX_62=0.6, 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 q-z+R2XbP6mO for ; Thu, 15 Nov 2012 15:40:44 -0800 (PST) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by ietfa.amsl.com (Postfix) with ESMTP id 8241821F885B for ; Thu, 15 Nov 2012 15:40:44 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKUKV9etE448Lq0pf8zlqqxsrJmfcd0isE@postini.com; Thu, 15 Nov 2012 15:40:44 PST Received: by shell-too.nominum.com (Postfix, from userid 11053) id 815571B8180; Thu, 15 Nov 2012 15:40:42 -0800 (PST) Date: Thu, 15 Nov 2012 15:40:42 -0800 From: Stephen Jacob To: Ted Lemon Message-ID: <20121115234042.GA11800@shell-too.nominum.com> Mail-Followup-To: Ted Lemon , Kevin Darcy , "" References: <50A56D7C.1030504@chrysler.com> <8D23D4052ABE7A4490E77B1A012B630747406804@mbx-01.win.nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630747406804@mbx-01.win.nominum.com> User-Agent: Mutt/1.4.2.2i X-URI: http://www.nominum.com/ Organization: Nominum, Inc. Cc: "" Subject: Re: [dhcwg] Unnecessary SSO Strictness on DHCPRELEASE? X-BeenThere: dhcwg@ietf.org 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, 15 Nov 2012 23:40:45 -0000 On Thu, Nov 15, 2012 at 10:54:49PM +0000, Ted Lemon wrote: > On Nov 15, 2012, at 5:32 PM, Kevin Darcy > wrote: > > "This option does not require changes to operations or features of the DHCP > > server other than to select the subnet on which to allocate an address." > > > > as in: "DHCP server implementations MUST NOT behave differently depending > > on the presence, absence or contents of an SSO, for DHCP transactions NOT > > involving allocation of an address"? > > No, the first sentence would translate, in the way you have proposed, to this: > > > as in: "DHCP server implementations MAY behave differently depending on the > > presence, absence or contents of an SSO, for DHCP transactions NOT > > involving allocation of an address"? > > IOW, "does not require" is not synonymous with "requires that there be no." I agree. > In this case, I would say that the client is most broken?it should send an > SSO consistently with every message, not just with initial messages. The > server is slightly broken?I'm pretty sure there's nothing in the RFC that > allows it to disregard a DHCPRELEASE simply because it doesn't contain an > SSO. I think I agree with this too. When I first read Kevin's query, my initial thought was that it made sense that one should always use the SSO, if present, to identify the link the client is on, thus determining what addresses it might be permitted to ... act upon in any way, but then when I thought about it more and verified in our server code base, I realised that, no, link does not in fact enter into consideration (in our interpretation) when processing a release. Link (as determined by giaddr, SSO, receiving interface if broadcast or source IPv6 address if processing a DHCPv4-over-IPv6 transaction) matters when deciding what addresses a client might be offered / is allowed to request, but it doesn't change the contract implied by a lease. Consider the following: 1. Client X is on link A, and is given a lease on address P. 2. Client X moves to link B. 3. Client X sends a release from link B for address P. If client X was on link A when they got a lease on address P, then moves to link B, it *still owns the lease on address P*, so I think it is perfectly reasonable that client X should be allowed to release its lease on address P. > The document is fairly broken. If you wanted to update it to explicitly > require that the client send an SSO in every packet relating to the lease > with which it first sent the SSO, I would support that effort. The question would still remain of what a server should do in response to a client not sending SSO. This would remain a problem server implementors would need to concern themselves with regardless of how the standard were changed. As I indicated above, though, this is not specific to SSO. SSO is just one of the factors in deciding link, and link is the attribute that an implementor needs to determine the relevance of in processing a release. > I think that would be a better fix than requiring that the server not behave > the way your server does?the behavior you're seeing in the server is more > like a non sequitur than a failure to accurately follow the spec. But it's > probably there because the server implementor either had to deal with or > expected to have to deal with DoS attacks from off-network. For this reason, I can imagine the current wording being better than a more strict, clarified text that limits implementors' options. If we do choose to clarify it, I think we need to be careful about not eliminating valid options. The one thing I would approve of, however, is saying that clients SHOULD be consistent in sending SSO. Either SSO is used to say what link they are on or it's not. I cannot think of any justification for why it would be desirable to drop the SSO from some messages. Regards, Stephen -- Stephen Jacob | Stephen.Jacob@nominum.com | +1 650 381 6051 Nominum, Inc. | http://www.nominum.com/ | +1 650 381 6000 From Stephen.Jacob@nominum.com Thu Nov 15 15:52:07 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 082D221F852D for ; Thu, 15 Nov 2012 15:52:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.849 X-Spam-Level: X-Spam-Status: No, score=-5.849 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, 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 9rgsyNB8c45P for ; Thu, 15 Nov 2012 15:52:06 -0800 (PST) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id 2748B21F850A for ; Thu, 15 Nov 2012 15:52:06 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKUKV/DHnLeqaOtZe0+gD6vCWofwnXtVWH@postini.com; Thu, 15 Nov 2012 15:52:06 PST Received: by shell-too.nominum.com (Postfix, from userid 11053) id 73BD41B8180; Thu, 15 Nov 2012 15:47:24 -0800 (PST) Date: Thu, 15 Nov 2012 15:47:24 -0800 From: Stephen Jacob To: Ted Lemon Message-ID: <20121115234724.GB11800@shell-too.nominum.com> Mail-Followup-To: Ted Lemon , Kevin Darcy , "" References: <50A56D7C.1030504@chrysler.com> <8D23D4052ABE7A4490E77B1A012B630747406804@mbx-01.win.nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630747406804@mbx-01.win.nominum.com> User-Agent: Mutt/1.4.2.2i X-URI: http://www.nominum.com/ Organization: Nominum, Inc. Cc: "" Subject: Re: [dhcwg] Unnecessary SSO Strictness on DHCPRELEASE? X-BeenThere: dhcwg@ietf.org 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, 15 Nov 2012 23:52:07 -0000 On Thu, Nov 15, 2012 at 10:54:49PM +0000, Ted Lemon wrote: > I think that would be a better fix than requiring that the server not behave > the way your server does?the behavior you're seeing in the server is more > like a non sequitur than a failure to accurately follow the spec. But it's > probably there because the server implementor either had to deal with or > expected to have to deal with DoS attacks from off-network. Oh, and one more thought: If one is concerned about DoS attacks from off-network, it seems more appropriate to protect against DHCP traffic from ourside one's network using firewalls than to impose a very weak constraint on DHCP messages. I don't think making DHCP servers less accepting of RELEASEs missing SSOs would improve security. About all it seems like it might do is stop a client from being a good network citizen and freeing up its no-longer-used lease early. Regards, Stephen -- Stephen Jacob | Stephen.Jacob@nominum.com | +1 650 381 6051 Nominum, Inc. | http://www.nominum.com/ | +1 650 381 6000 From jiangsheng@huawei.com Thu Nov 15 16:51: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 44BA91F0C70; Thu, 15 Nov 2012 16:51:28 -0800 (PST) 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 HEmsmY8fEh05; Thu, 15 Nov 2012 16:51:27 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id EA8CB1F0C6A; Thu, 15 Nov 2012 16:51:25 -0800 (PST) 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 ALP58081; Fri, 16 Nov 2012 00:51:23 +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; Fri, 16 Nov 2012 00:51:07 +0000 Received: from SZXEML424-HUB.china.huawei.com (10.82.67.163) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 16 Nov 2012 00:51:22 +0000 Received: from szxeml545-mbx.china.huawei.com ([169.254.1.6]) by szxeml424-hub.china.huawei.com ([10.82.67.163]) with mapi id 14.01.0323.003; Fri, 16 Nov 2012 08:51:17 +0800 From: Sheng Jiang To: joel jaeggli , "draft-ietf-dhc-addr-registration@tools.ietf.org" , IPv6 Ops WG , "dhcwg@ietf.org" Thread-Topic: [v6ops] some feedback on http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-01 Thread-Index: AQHNwjRAZyoNeWfvHE6KhAKB8QhDcZfropKQ Date: Fri, 16 Nov 2012 00:51:16 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B9239F8E40C@szxeml545-mbx.china.huawei.com> References: <50A33EFA.7070008@bogus.com> In-Reply-To: <50A33EFA.7070008@bogus.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.140] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [dhcwg] [v6ops] some feedback on http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-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, 16 Nov 2012 00:51:29 -0000 PlRoZXJlJ3MgYSBjb3VwbGUgaXNzdWVzIHRoYXQgYXJlIHF1aXRlIHN0cmlraW5nLiBJIGtpbmQg b2YgY29uY3VyIHdpdGgNCj5GcmVkICBCYWtlciB0aGF0IHRoZSBtb3N0IGFwcHJvcGlhdGUgbWV0 aG9kIGZvciB0cmFja2luZyBsMi9sMyBiaW5kaW5nDQo+Zm9yIGFkZHJlc3MgaWRlbnRpZmljYXRp b24gaXMgcHJvYmFibHkgbW9yZSBha2luIHRvIHN5c2xvZy4NCj4NCj5UaGF0IGlzLCBzaW5jZSB5 b3UgZG9uJ3QgcmVhbGx5IHRydXN0IHRoZSBob3N0cywgaGF2aW5nIGEgc3dpdGNoL3JvdXRlciwN Cj5zaW1wbHkgc3lzbG9naW5nIGFsbCBuZXcgTkRQIGNhY2hlIGVudHJpZXMgcHJldHR5IG11Y2gg YWNoaXZlcyB0aGUgc2FtZQ0KPnRoaW5nIGV4ZWNlcHQgd2l0aCBhIGxvdCBsZXNzIHNpZ25hbGlu Zy4NCg0KSGksIEpvZWwsDQoNCkkgYW0gbm90IGFncmVlIHRoZSBwcmVjb25kaXRpb24geW91IGhh dmUgaGVyZTogInNpbmNlIHlvdSBkb24ndCByZWFsbHkgdHJ1c3QgdGhlIGhvc3RzIi4gVGhlIGFz c3VtZSB3ZSB0YWtlIGlzIHRoYXQgaG9zdHMsIGF0IGxlYXN0IGhvc3QgSVAgc3RhY2ssIHdvdWxk IGRvIHRoaXMgcmlnaHQuIE9yIGF0IGxlYXN0IHRoZXkgd2lsbCBkbyByaWdodCB0aGluZ3MgYnkg c3RhbmRhcmQgZGVmaW5pdGlvbnMuIEluIHJlYWxpdHksIG1hbGljaW91cyBob3N0cyBkbyBub3Qg Zm9sbG93IHRoZSBSRkNzLiBUaGVyZWZvcmUsIHRoZXkgYXJlIGNvbnNpZGVyZWQgYXMgc2VjdXJp dHkgaXNzdWVzLiBJdCBvbmx5IG1lYW5zIG1vcmUgc2VjdXJpdHkgbWVjaGFuaXNtL2luZnJhc3Ry dWN0dXJlIHNob3VsZCBiZSBkZXBsb3llZC4gSXQgc2hvdWxkIG5vdCBkZW55IHRoZSBtZWFuaW5n IG9mIGFkZHJlc3MgcmVnaXN0cmF0aW9uLiBJdCBzZXJ2ZXJzIG1vc3Qgb2Ygb3JkaW5hcnkgaG9z dHMsIHdoaWNoIG1heSBiZSA5OSUgb2YgYWxsIHVzZXJzLg0KDQpCZXN0IHJlZ2FyZHMsDQoNClNo ZW5nDQoNCj5JZiBhIHN0cm9uZyBhc3NlcnRpb24gb2YgTDIgaWRlbnRpdHkgaW4gc3VwcG9ydCBv ZiBsMi9sMyBiaW5kaW5ncyBpcw0KPnJlcXVpcmVkIDgwMi4xeCBvciB0aGUgd2lyZWxlc3MgZXF1 aXZhbGFuZXQgc2VlbXMgYXBwcm9waWF0ZSwgZS5nLiBpdCdzDQo+d2hhdCB3ZSBkbyB0b2RheS4N Cj4NCj5BdmFpbGluZyBvbmVzZWxmIG9mIGEgZGhjcC9yYSBvcHRpb24gZW50YWlscyBhIGxvdCBv ZiBzaWduYWxpbmcgZm9yIHdoYXQNCj5pcyBsaWtlbHkgYSByZWxhdGl2ZWx5IGVwaGVtZXJhbCBw b3J0ICh3aW5kb3dzIG1hY2hpbmVzIGFuZCBtYWNzDQo+cmVnaXN0ZXJpbmcgcHJpdmFjeSBhZGRy ZXNzZXMgZm9yIGV4YW1wbGUpLiBzcGVjaWZpeWluZyBhIGJpbmRpbmcNCj5saWZldGltZSBzZWVt cyBvZiBsaW1pdGVkIHV0aWxpdHkgc2luY2UgdGhlIGhvc3Qgd2lsbCBwcm9iYWJseSBkaXNjYXJk DQo+dGhlIGFkZHJlc3MgbG9uZyBiZWZvcmUgdGhlIGxpZmV0aW1lIGV4cGlyZXMgaWYgaXQncyBz dWZmaWNlbnRseSBsb25nDQo+ZW5vdWdoIHRvIGFsbG93IGZvciBsb25nIGxpdmVkIGNvbm5lY3Rp b25zIHVzaW5nIHRoYXQgYWRkcmVzcy4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPnY2b3BzIG1haWxpbmcgbGlzdA0KPnY2b3BzQGlldGYub3JnDQo+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0K From jiangsheng@huawei.com Thu Nov 15 16:56: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 F196521F85EF; Thu, 15 Nov 2012 16:56:33 -0800 (PST) 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 KjvkAUi1IzaE; Thu, 15 Nov 2012 16:56:31 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 32A7521F85E7; Thu, 15 Nov 2012 16:56:29 -0800 (PST) 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 ALP58301; Fri, 16 Nov 2012 00:56:29 +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; Fri, 16 Nov 2012 00:56:12 +0000 Received: from SZXEML428-HUB.china.huawei.com (10.72.61.36) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 16 Nov 2012 00:56:28 +0000 Received: from szxeml545-mbx.china.huawei.com ([169.254.1.6]) by szxeml428-hub.china.huawei.com ([10.72.61.36]) with mapi id 14.01.0323.003; Fri, 16 Nov 2012 08:56:22 +0800 From: Sheng Jiang To: joel jaeggli , "draft-ietf-dhc-addr-registration@tools.ietf.org" , IPv6 Ops WG , "dhcwg@ietf.org" Thread-Topic: [v6ops] some feedback on http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-01 Thread-Index: AQHNwjRAZyoNeWfvHE6KhAKB8QhDcZfrpcEg Date: Fri, 16 Nov 2012 00:56:21 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B9239F8E437@szxeml545-mbx.china.huawei.com> References: <50A33EFA.7070008@bogus.com> In-Reply-To: <50A33EFA.7070008@bogus.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.140] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [dhcwg] [v6ops] some feedback on http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-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, 16 Nov 2012 00:56:34 -0000 DQoNCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IHY2b3BzLWJvdW5jZXNAaWV0 Zi5vcmcgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj5PZiBqb2Vs IGphZWdnbGkNCj5TZW50OiBXZWRuZXNkYXksIE5vdmVtYmVyIDE0LCAyMDEyIDI6NTAgUE0NCj5U bzogZHJhZnQtaWV0Zi1kaGMtYWRkci1yZWdpc3RyYXRpb25AdG9vbHMuaWV0Zi5vcmc7IElQdjYg T3BzIFdHOw0KPmRoY3dnQGlldGYub3JnDQo+U3ViamVjdDogW3Y2b3BzXSBzb21lIGZlZWRiYWNr IG9uDQo+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1kaGMtYWRkci1yZWdp c3RyYXRpb24tMDENCj4NCj5JIHRvb2sgYSBsb29rIGF0IHRoaXMgZHJhZnQgc2luY2UgaXQgd2Fz IGFsc28gcHJlc2VudGVkIGluIHY2b3BzLi4uDQo+DQo+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi1kaGMtYWRkci1yZWdpc3RyYXRpb24tMDENCj4NCj5UaGVyZSdzIGEgY291 cGxlIGlzc3VlcyB0aGF0IGFyZSBxdWl0ZSBzdHJpa2luZy4gSSBraW5kIG9mIGNvbmN1ciB3aXRo DQo+RnJlZCAgQmFrZXIgdGhhdCB0aGUgbW9zdCBhcHByb3BpYXRlIG1ldGhvZCBmb3IgdHJhY2tp bmcgbDIvbDMgYmluZGluZw0KPmZvciBhZGRyZXNzIGlkZW50aWZpY2F0aW9uIGlzIHByb2JhYmx5 IG1vcmUgYWtpbiB0byBzeXNsb2cuDQo+DQo+VGhhdCBpcywgc2luY2UgeW91IGRvbid0IHJlYWxs eSB0cnVzdCB0aGUgaG9zdHMsIGhhdmluZyBhIHN3aXRjaC9yb3V0ZXIsDQo+c2ltcGx5IHN5c2xv Z2luZyBhbGwgbmV3IE5EUCBjYWNoZSBlbnRyaWVzIHByZXR0eSBtdWNoIGFjaGl2ZXMgdGhlIHNh bWUNCj50aGluZyBleGVjZXB0IHdpdGggYSBsb3QgbGVzcyBzaWduYWxpbmcuDQo+DQo+SWYgYSBz dHJvbmcgYXNzZXJ0aW9uIG9mIEwyIGlkZW50aXR5IGluIHN1cHBvcnQgb2YgbDIvbDMgYmluZGlu Z3MgaXMNCj5yZXF1aXJlZCA4MDIuMXggb3IgdGhlIHdpcmVsZXNzIGVxdWl2YWxhbmV0IHNlZW1z IGFwcHJvcGlhdGUsIGUuZy4gaXQncw0KPndoYXQgd2UgZG8gdG9kYXkuDQo+DQo+QXZhaWxpbmcg b25lc2VsZiBvZiBhIGRoY3AvcmEgb3B0aW9uIGVudGFpbHMgYSBsb3Qgb2Ygc2lnbmFsaW5nIGZv ciB3aGF0DQo+aXMgbGlrZWx5IGEgcmVsYXRpdmVseSBlcGhlbWVyYWwgcG9ydCAod2luZG93cyBt YWNoaW5lcyBhbmQgbWFjcw0KPnJlZ2lzdGVyaW5nIHByaXZhY3kgYWRkcmVzc2VzIGZvciBleGFt cGxlKS4gc3BlY2lmaXlpbmcgYSBiaW5kaW5nDQo+bGlmZXRpbWUgc2VlbXMgb2YgbGltaXRlZCB1 dGlsaXR5IHNpbmNlIHRoZSBob3N0IHdpbGwgcHJvYmFibHkgZGlzY2FyZA0KPnRoZSBhZGRyZXNz IGxvbmcgYmVmb3JlIHRoZSBsaWZldGltZSBleHBpcmVzIGlmIGl0J3Mgc3VmZmljZW50bHkgbG9u Zw0KPmVub3VnaCB0byBhbGxvdyBmb3IgbG9uZyBsaXZlZCBjb25uZWN0aW9ucyB1c2luZyB0aGF0 IGFkZHJlc3MuDQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj52Nm9wcyBtYWlsaW5nIGxpc3QNCj52Nm9wc0BpZXRmLm9yZw0KPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCg== From joelja@bogus.com Thu Nov 15 17:51: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 1546B1F0C49; Thu, 15 Nov 2012 17:51:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.228 X-Spam-Level: X-Spam-Status: No, score=-102.228 tagged_above=-999 required=5 tests=[AWL=-0.229, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HcAiNrGATG4l; Thu, 15 Nov 2012 17:51:32 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 80DE31F0C44; Thu, 15 Nov 2012 17:51:32 -0800 (PST) Received: from joels-MacBook-Air.local (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id qAG1pRfY075727 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 16 Nov 2012 01:51:29 GMT (envelope-from joelja@bogus.com) Message-ID: <50A59C1F.2040407@bogus.com> Date: Thu, 15 Nov 2012 17:51:27 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Sheng Jiang References: <50A33EFA.7070008@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8E40C@szxeml545-mbx.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B9239F8E40C@szxeml545-mbx.china.huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Fri, 16 Nov 2012 01:51:29 +0000 (UTC) Cc: "dhcwg@ietf.org" , IPv6 Ops WG , "draft-ietf-dhc-addr-registration@tools.ietf.org" Subject: Re: [dhcwg] [v6ops] some feedback on http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-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, 16 Nov 2012 01:51:33 -0000 On 11/15/12 4:51 PM, Sheng Jiang wrote: >> There's a couple issues that are quite striking. I kind of concur with >> Fred Baker that the most appropiate method for tracking l2/l3 binding >> for address identification is probably more akin to syslog. >> >> That is, since you don't really trust the hosts, having a switch/router, >> simply sysloging all new NDP cache entries pretty much achives the same >> thing execept with a lot less signaling. > Hi, Joel, > > I am not agree the precondition you have here: "since you don't really trust the hosts". The assume we take is that hosts, at least host IP stack, would do this right. Or at least they will do right things by standard definitions. That's an interesting assumption given that all pre-existing host stacks will be unaware of the availability of the mechanism and therefore not use it. > In reality, malicious hosts do not follow the RFCs. untrustworthy hosts aren't necessarily malicious. > Therefore, they are considered as security issues. It only means more security mechanism/infrastructure should be deployed. It should not deny the meaning of address registration. It servers most of ordinary hosts, which may be 99% of all users. I can with relatively minor effort on the part of a vendor capture the same information, with a lot less signaling out of the NDP cache on my routers, and do so without consideration of hosts behavior. > Best regards, > > Sheng > >> If a strong assertion of L2 identity in support of l2/l3 bindings is >> required 802.1x or the wireless equivalanet seems appropiate, e.g. it's >> what we do today. >> >> Availing oneself of a dhcp/ra option entails a lot of signaling for what >> is likely a relatively ephemeral port (windows machines and macs >> registering privacy addresses for example). specifiying a binding >> lifetime seems of limited utility since the host will probably discard >> the address long before the lifetime expires if it's sufficently long >> enough to allow for long lived connections using that address. >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops From leaf.y.yeh@huawei.com Thu Nov 15 18:25: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 7E02921F841C for ; Thu, 15 Nov 2012 18:25:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.509 X-Spam-Level: X-Spam-Status: No, score=-6.509 tagged_above=-999 required=5 tests=[AWL=0.090, 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 Bqc62ncgG5Cf for ; Thu, 15 Nov 2012 18:25:07 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B807C21F8232 for ; Thu, 15 Nov 2012 18:25:06 -0800 (PST) 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 AMV65829; Fri, 16 Nov 2012 02:23:32 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 16 Nov 2012 02:23:13 +0000 Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 16 Nov 2012 02:23:29 +0000 Received: from SZXEML546-MBX.china.huawei.com ([169.254.3.157]) by szxeml402-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Fri, 16 Nov 2012 10:23:22 +0800 From: Leaf yeh To: Maglione Roberta , " WG" Thread-Topic: WGLC: draft-ietf-dhc-dhcpv6-radius-opt-04 Thread-Index: AQHNwnuJXxc1SNgKKEqdICsCoFzJ1ZfqqxqwgAEHqaA= Date: Fri, 16 Nov 2012 02:23:21 +0000 Message-ID: References: <8D23D4052ABE7A4490E77B1A012B630747405925@mbx-01.win.nominum.com> <282BBE8A501E1F4DA9C775F964BB21FE519AC44BE1@GRFMBX704BA020.griffon.local> In-Reply-To: <282BBE8A501E1F4DA9C775F964BB21FE519AC44BE1@GRFMBX704BA020.griffon.local> 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: 'Ted Lemon' Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-radius-opt-04 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 02:25:08 -0000 Roberta - I would suggest adding at the end "additional attributes may be a= dded to this list in future according to new RADIUS attributes specificatio= ns" The following text in section 9, IANA consideration, ' The RADIUS Attribute may be added to this list after IETF Review [RFC5= 226].'=20 could be updated to be 'New RADIUS Attribute may be added to this list after Expert Review [RFC= 5226].' How about to copy the same sentence into section 4, DHCPv6 RADIUS option? = =20 It sounds more smooth than the above text '...added to this list in future = according to new RADIUS attributes specifications ' to me. I definitely sup= port the new draft-ietf or RFC with the definition of new RADIUS attribute,= would suggest the potential expert review for the adding into the new IANA= Registry of 'RADIUS Attributes Permitted in the DHCPv6 RADIUS option'. Best Regards, Leaf -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of M= aglione Roberta Sent: Thursday, November 15, 2012 6:06 PM To: 'Ted Lemon'; WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-radius-opt-04 Hello, I have read the draft and I support this work. I have a comment: Section 4 says: " The RADIUS attributes listed in the below table are recom= mended as the first batch of attributes in the IANA Registry of 'RADIUS Attributes Permitted in the DHCPv6 RADIUS option'" I would suggest adding at the end "additional attributes may be added to this list in future according to new= RADIUS attributes specifications" A part from that I am in favor of advancing this draft. Regards Roberta -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= ed Lemon Sent: Wednesday, November 14, 2012 4:20 PM To: WG Subject: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-radius-opt-04 The authors of this document have requested a working group last call. Th= e document describes a mechanism, similar to the mechanism in DHCPv4, for c= arrying RADIUS options in DHCP packets. If this is of interest to you, pl= ease review the draft: http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-radius-opt-04 If you have comments, please send them to the working group mailing list. = If you are in favor of advancing the document as it is, please reply to th= is message and say so. If you do not favor advancing the document, and do= not have specific comments, please reply to this message indicating that y= ou don't favor advancing the document. Since the document has my name on it, John will be doing the evaluation of = consensus. He will do this on or after November 28. Thanks! _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From jiangsheng@huawei.com Thu Nov 15 18:33: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 AED9A21F84C7; Thu, 15 Nov 2012 18:33:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 65GQ79U95bE3; Thu, 15 Nov 2012 18:33:57 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id EF5EB11E8097; Thu, 15 Nov 2012 18:33:55 -0800 (PST) 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 ALP62451; Fri, 16 Nov 2012 02:33:54 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 16 Nov 2012 02:33:39 +0000 Received: from SZXEML416-HUB.china.huawei.com (10.82.67.155) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 16 Nov 2012 02:33:53 +0000 Received: from szxeml545-mbx.china.huawei.com ([169.254.1.6]) by szxeml416-hub.china.huawei.com ([10.82.67.155]) with mapi id 14.01.0323.003; Fri, 16 Nov 2012 10:33:49 +0800 From: Sheng Jiang To: joel jaeggli Thread-Topic: [v6ops] some feedback on http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-01 Thread-Index: AQHNw5zqb/SB0+d2NUqed+yzFK7R8pfrtqcg Date: Fri, 16 Nov 2012 02:33:49 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B9239F8E520@szxeml545-mbx.china.huawei.com> References: <50A33EFA.7070008@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8E40C@szxeml545-mbx.china.huawei.com> <50A59C1F.2040407@bogus.com> In-Reply-To: <50A59C1F.2040407@bogus.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.140] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "dhcwg@ietf.org" , IPv6 Ops WG , "draft-ietf-dhc-addr-registration@tools.ietf.org" Subject: Re: [dhcwg] [v6ops] some feedback on http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-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, 16 Nov 2012 02:33:57 -0000 Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogam9lbCBqYWVnZ2xpIFttYWlsdG86 am9lbGphQGJvZ3VzLmNvbV0NCj5TZW50OiBGcmlkYXksIE5vdmVtYmVyIDE2LCAyMDEyIDk6NTEg QU0NCj5UbzogU2hlbmcgSmlhbmcNCj5DYzogZHJhZnQtaWV0Zi1kaGMtYWRkci1yZWdpc3RyYXRp b25AdG9vbHMuaWV0Zi5vcmc7IElQdjYgT3BzIFdHOw0KPmRoY3dnQGlldGYub3JnDQo+U3ViamVj dDogUmU6IFt2Nm9wc10gc29tZSBmZWVkYmFjayBvbg0KPmh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYtZGhjLWFkZHItcmVnaXN0cmF0aW9uLTAxDQo+DQo+T24gMTEvMTUvMTIg NDo1MSBQTSwgU2hlbmcgSmlhbmcgd3JvdGU6DQo+Pj4gVGhlcmUncyBhIGNvdXBsZSBpc3N1ZXMg dGhhdCBhcmUgcXVpdGUgc3RyaWtpbmcuIEkga2luZCBvZiBjb25jdXIgd2l0aA0KPj4+IEZyZWQg IEJha2VyIHRoYXQgdGhlIG1vc3QgYXBwcm9waWF0ZSBtZXRob2QgZm9yIHRyYWNraW5nIGwyL2wz IGJpbmRpbmcNCj4+PiBmb3IgYWRkcmVzcyBpZGVudGlmaWNhdGlvbiBpcyBwcm9iYWJseSBtb3Jl IGFraW4gdG8gc3lzbG9nLg0KPj4+DQo+Pj4gVGhhdCBpcywgc2luY2UgeW91IGRvbid0IHJlYWxs eSB0cnVzdCB0aGUgaG9zdHMsIGhhdmluZyBhIHN3aXRjaC9yb3V0ZXIsDQo+Pj4gc2ltcGx5IHN5 c2xvZ2luZyBhbGwgbmV3IE5EUCBjYWNoZSBlbnRyaWVzIHByZXR0eSBtdWNoIGFjaGl2ZXMgdGhl IHNhbWUNCj4+PiB0aGluZyBleGVjZXB0IHdpdGggYSBsb3QgbGVzcyBzaWduYWxpbmcuDQo+PiBI aSwgSm9lbCwNCj4+DQo+PiBJIGFtIG5vdCBhZ3JlZSB0aGUgcHJlY29uZGl0aW9uIHlvdSBoYXZl IGhlcmU6ICJzaW5jZSB5b3UgZG9uJ3QgcmVhbGx5IHRydXN0DQo+dGhlIGhvc3RzIi4gVGhlIGFz c3VtZSB3ZSB0YWtlIGlzIHRoYXQgaG9zdHMsIGF0IGxlYXN0IGhvc3QgSVAgc3RhY2ssIHdvdWxk IGRvDQo+dGhpcyByaWdodC4gT3IgYXQgbGVhc3QgdGhleSB3aWxsIGRvIHJpZ2h0IHRoaW5ncyBi eSBzdGFuZGFyZCBkZWZpbml0aW9ucy4NCj5UaGF0J3MgYW4gaW50ZXJlc3RpbmcgYXNzdW1wdGlv biBnaXZlbiB0aGF0IGFsbCBwcmUtZXhpc3RpbmcgaG9zdCBzdGFja3MNCj53aWxsIGJlIHVuYXdh cmUgb2YgdGhlIGF2YWlsYWJpbGl0eSBvZiB0aGUgbWVjaGFuaXNtIGFuZCB0aGVyZWZvcmUgbm90 DQo+dXNlIGl0Lg0KDQpUaGlzIGFyZ3VtZW50IHNlZW1zIHRvbyB3aWRlLiBJZiBzbywgb3VyIElF VEYgc2hvdWxkIG5ldmVyIGRlZmluZSBhbnkgbmV3IGV4dGVuc2lvbiBoZWFkZXJzL29wdGlvbnMv bWVjaGFuaXNtcyBiZWNhdXNlIGFsbCBwcmUtZXhpc3RpbmcgaG9zdCBzdGFja3MgZG8gbm90IHVu YXdhcmUgdGhlbS4NCg0KRm9yIG1lLCB5b3VyIGFyZ3VtZW50IGlzIGF2YWlsYWJsZSBpZiBpdCBj b21lcyBsaWtlIHRoaXMgd2F5OiB0aGVyZSBzaG91bGQgYmUgbW9yZSBjb25zaWRlcmF0aW9ucyBm b3IgaG93IHRvIHN1cHBvcnQgYmFja3dhcmRzIGNvbXBhdGliaWxpdHkuIFdlIGNhbiB3b3JrIG9u IHRoYXQuDQoNCj4+ICAgSW4gcmVhbGl0eSwgbWFsaWNpb3VzIGhvc3RzIGRvIG5vdCBmb2xsb3cg dGhlIFJGQ3MuDQo+dW50cnVzdHdvcnRoeSBob3N0cyBhcmVuJ3QgbmVjZXNzYXJpbHkgbWFsaWNp b3VzLg0KDQpPay4gTGV0J3MgZGlzY3VzcyB3aGljaCBwYXJ0IHlvdSBkb24ndCB0cnVzdCBmcm9t IGhvc3RzLiBUaGVyZSBhcmUgc2V2ZXJhbCBwb3NzaWJpbGl0aWVzIEkgY2FuIHRoaW5rIG91dDog YSkgaG9zdHMgcmVmdXNlIHRvIHJlZ2lzdGVyIHRoZWlyIGFkZHJlc3NlcywgYikgaG9zdHMgcmVn aXN0ZXIgd3JvbmcgYWRkcmVzcy9tYWMgb24gcHVycG9zZSBjKSBob3N0IHN0YWNrcyBkb2VzIG5v dCByZWdpc3RlciBhZGRyZXNzL21hYyByaWdodC4gRm9yIG1lLCBhIGhhcyBiZWVuIGRlc2NyaWJl ZCBpbiB0aGUgZHJhZnQ7IGIgc2hvdWxkIGJlIGNvbnNpZGVyIGFzIG1hbGljaW91cyBiZWhhdmlv cjsgYyBpcyBkb3duIHRvIGltcGxlbWVudGF0aW9uLCBpdCBpcyBub3QgYSBzdGFuZGFyZCBpc3N1 ZS4NCg0KSWYgeW91IGhhdmUgb3RoZXIgdW50cnVzdHdvcnRoeSBjb25zaWRlcmF0aW9ucywgcGxl YXNlIGdpdmUgZGV0YWlscy4gSSBhbSBoYXBweSB0byBkaXNjdXNzIHRoZW0uDQoNCj4+ICAgVGhl cmVmb3JlLCB0aGV5IGFyZSBjb25zaWRlcmVkIGFzIHNlY3VyaXR5IGlzc3Vlcy4gSXQgb25seSBt ZWFucyBtb3JlDQo+c2VjdXJpdHkgbWVjaGFuaXNtL2luZnJhc3RydWN0dXJlIHNob3VsZCBiZSBk ZXBsb3llZC4gSXQgc2hvdWxkIG5vdCBkZW55IHRoZQ0KPm1lYW5pbmcgb2YgYWRkcmVzcyByZWdp c3RyYXRpb24uIEl0IHNlcnZlcnMgbW9zdCBvZiBvcmRpbmFyeSBob3N0cywgd2hpY2ggbWF5DQo+ YmUgOTklIG9mIGFsbCB1c2Vycy4NCj5JIGNhbiB3aXRoIHJlbGF0aXZlbHkgbWlub3IgZWZmb3J0 IG9uIHRoZSBwYXJ0IG9mIGEgdmVuZG9yIGNhcHR1cmUgdGhlDQo+c2FtZSBpbmZvcm1hdGlvbiwg d2l0aCBhIGxvdCBsZXNzIHNpZ25hbGluZyBvdXQgb2YgdGhlIE5EUCBjYWNoZSBvbiBteQ0KPnJv dXRlcnMsIGFuZCBkbyBzbyB3aXRob3V0IGNvbnNpZGVyYXRpb24gb2YgaG9zdHMgYmVoYXZpb3Iu DQoNCkkgYWdyZWUgd2l0aCB5b3UgaWYgd2Ugb25seSBkaXNjdXNzIHRoZSBzY2VuYXJpbyB0aGF0 IGZpcnN0LWhvcCByb3V0ZXIgaXMgZnVsbHkgdW5kZXIgbWFuYWdlbWVudCBieSBJU1BzLiBCdXQg dGhlcmUgYXJlIG90aGVyIHNjZW5hcmlvcywgaW4gd2hpY2ggZmlyc3QtaG9wIHJvdXRlciBpcyBo b21lIGdhdGV3YXksIG1vYmlsZSBub2RlIGFuZCBvdGhlcnMuIEZvciB0aGVzZSBzY2VuYXJpb3Ms IElTUCBjYW5ub3QgZ2V0IHRoZSBhZGRyZXNzIGluZm9ybWF0aW9uIHVubGVzcyBob3N0IHJlZ2lz dGVyaW5nLg0KDQpBbm90aGVyIHBvaW50IGlzIHRoaXMgbmV3IHJlZ2lzdHJhdGlvbiBpcyBiaS1k aXJlY3Rpb24gaW50ZXJhY3Rpb24uIEl0IGdpdmVzIElTUHMgYSBjaGFuY2UgdG8gbWFuYWdlIHRo ZXNlIGhvc3QtZ2VuZXJhdGVkIGFkZHJlc3Nlcywgc3VjaCBhcyBkZW55aW5nIGNlcnRhaW4gYWRk cmVzcyAoc3VjaCBhcyBsb3cgc2VjLXZhbHVlIENHQSksIGV0Yy4gRm9yIG5vdywgSVNQcyBoYXMg dG8gYWNjZXB0IGFsbCBob3N0LWdlbmVyYXRlZCBhZGRyZXNzZXMuIElmIElTUCBkZW5pZXMgYWNj ZXNzIGJlY2F1c2Ugb2YgYW55IGFkZHJlc3MtcmVsZXZhbnQgcmVhc29ucywgdGhlcmUgaXMgbm8g bWVjaGFuaXNtIHRvIHRlbGwgaG9zdHMgd2h5IGFuZCBob3cgdG8gZml4IGl0Lg0KDQpCZXN0IHJl Z2FyZHMsDQoNClNoZW5nDQoNCj4+IEJlc3QgcmVnYXJkcywNCj4+DQo+PiBTaGVuZw0KPj4NCj4+ PiBJZiBhIHN0cm9uZyBhc3NlcnRpb24gb2YgTDIgaWRlbnRpdHkgaW4gc3VwcG9ydCBvZiBsMi9s MyBiaW5kaW5ncyBpcw0KPj4+IHJlcXVpcmVkIDgwMi4xeCBvciB0aGUgd2lyZWxlc3MgZXF1aXZh bGFuZXQgc2VlbXMgYXBwcm9waWF0ZSwgZS5nLiBpdCdzDQo+Pj4gd2hhdCB3ZSBkbyB0b2RheS4N Cj4+Pg0KPj4+IEF2YWlsaW5nIG9uZXNlbGYgb2YgYSBkaGNwL3JhIG9wdGlvbiBlbnRhaWxzIGEg bG90IG9mIHNpZ25hbGluZyBmb3Igd2hhdA0KPj4+IGlzIGxpa2VseSBhIHJlbGF0aXZlbHkgZXBo ZW1lcmFsIHBvcnQgKHdpbmRvd3MgbWFjaGluZXMgYW5kIG1hY3MNCj4+PiByZWdpc3RlcmluZyBw cml2YWN5IGFkZHJlc3NlcyBmb3IgZXhhbXBsZSkuIHNwZWNpZml5aW5nIGEgYmluZGluZw0KPj4+ IGxpZmV0aW1lIHNlZW1zIG9mIGxpbWl0ZWQgdXRpbGl0eSBzaW5jZSB0aGUgaG9zdCB3aWxsIHBy b2JhYmx5IGRpc2NhcmQNCj4+PiB0aGUgYWRkcmVzcyBsb25nIGJlZm9yZSB0aGUgbGlmZXRpbWUg ZXhwaXJlcyBpZiBpdCdzIHN1ZmZpY2VudGx5IGxvbmcNCj4+PiBlbm91Z2ggdG8gYWxsb3cgZm9y IGxvbmcgbGl2ZWQgY29ubmVjdGlvbnMgdXNpbmcgdGhhdCBhZGRyZXNzLg0KPj4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gdjZvcHMgbWFpbGlu ZyBsaXN0DQo+Pj4gdjZvcHNAaWV0Zi5vcmcNCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3Y2b3BzDQoNCg== From joelja@bogus.com Thu Nov 15 20: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 BF9D621E8040; Thu, 15 Nov 2012 20:05:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.199 X-Spam-Level: X-Spam-Status: No, score=-102.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UdNyslrDGgMs; Thu, 15 Nov 2012 20:05:40 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 07EF921E802E; Thu, 15 Nov 2012 20:05:39 -0800 (PST) Received: from joels-MacBook-Air.local (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id qAG45Z8f077831 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 16 Nov 2012 04:05:36 GMT (envelope-from joelja@bogus.com) Message-ID: <50A5BB8E.6010308@bogus.com> Date: Thu, 15 Nov 2012 20:05:34 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Sheng Jiang References: <50A33EFA.7070008@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8E40C@szxeml545-mbx.china.huawei.com> <50A59C1F.2040407@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8E520@szxeml545-mbx.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B9239F8E520@szxeml545-mbx.china.huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Fri, 16 Nov 2012 04:05:37 +0000 (UTC) Cc: "dhcwg@ietf.org" , IPv6 Ops WG , "draft-ietf-dhc-addr-registration@tools.ietf.org" Subject: Re: [dhcwg] [v6ops] some feedback on http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-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, 16 Nov 2012 04:05:40 -0000 On 11/15/12 6:33 PM, Sheng Jiang wrote: >> -----Original Message----- >> From: joel jaeggli [mailto:joelja@bogus.com] >> Sent: Friday, November 16, 2012 9:51 AM >> To: Sheng Jiang >> Cc: draft-ietf-dhc-addr-registration@tools.ietf.org; IPv6 Ops WG; >> dhcwg@ietf.org >> Subject: Re: [v6ops] some feedback on >> http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-01 >> >> On 11/15/12 4:51 PM, Sheng Jiang wrote: >>>> There's a couple issues that are quite striking. I kind of concur with >>>> Fred Baker that the most appropiate method for tracking l2/l3 binding >>>> for address identification is probably more akin to syslog. >>>> >>>> That is, since you don't really trust the hosts, having a switch/router, >>>> simply sysloging all new NDP cache entries pretty much achives the same >>>> thing execept with a lot less signaling. >>> Hi, Joel, >>> >>> I am not agree the precondition you have here: "since you don't really trust >> the hosts". The assume we take is that hosts, at least host IP stack, would do >> this right. Or at least they will do right things by standard definitions. >> That's an interesting assumption given that all pre-existing host stacks >> will be unaware of the availability of the mechanism and therefore not >> use it. > This argument seems too wide. If so, our IETF should never define any new extension headers/options/mechanisms because all pre-existing host stacks do not unaware them. There should be a pretty high standard associated with changing the behavior of things which already exist. > For me, your argument is available if it comes like this way: there should be more considerations for how to support backwards compatibility. We can work on that. > >>> In reality, malicious hosts do not follow the RFCs. >> untrustworthy hosts aren't necessarily malicious. > Ok. Let's discuss which part you don't trust from hosts. There are several possibilities I can think out: a) hosts refuse to register their addresses, b) hosts register wrong address/mac on purpose What is wrong MAC in this case? MACs are generally but not always stable (vrrp6 is a pretty good case for not stable), in any event they are reconfigurable. A MAC is a layer 2 binding and if you have a strong layer-2 authentication (as some centrally managed networks do) then forgery is essentially irrelvant. beyond that the correctness of a MAC absent ACLs, is limited to it's presence in the bridge table and any l2/l3 bindings it may have. > c) host stacks does not register address/mac right. For me, a has been described in the draft; b should be consider as malicious behavior; c is down to implementation, it is not a standard issue. > > If you have other untrustworthy considerations, please give details. I am happy to discuss them. > >>> Therefore, they are considered as security issues. It only means more >> security mechanism/infrastructure should be deployed. It should not deny the >> meaning of address registration. It servers most of ordinary hosts, which may >> be 99% of all users. >> I can with relatively minor effort on the part of a vendor capture the >> same information, with a lot less signaling out of the NDP cache on my >> routers, and do so without consideration of hosts behavior. > I agree with you if we only discuss the scenario that first-hop router is fully under management by ISPs. But there are other scenarios, in which first-hop router is home gateway, mobile node and others. For these scenarios, ISP cannot get the address information unless host registering. Either the network is centrally managed or it isn't. The draft describes a management entity (enterprise) which is fully in control of the first hop router(s). Here you're describing a transitory trust model where my first hop router managed by me passes a registration option to my hosts to register addresses used on my network with my ISP. That's not, in your document. The network in my house, or my enterprise is managed by me, my ISP once they've assigned or delegated a prefix doesn't get to determine if I can use an address or not. It is no business of my ISP, if my fridge, or thermostat decides to use SLAAC to assign an address from the prefix which it plans to use becuase it's covered by RA. > Another point is this new registration is bi-direction interaction. It gives ISPs a chance to manage these host-generated addresses, such as denying certain address (such as low sec-value CGA), etc. For now, ISPs has to accept all host-generated addresses. If ISP denies access because of any address-relevant reasons, there is no mechanism to tell hosts why and how to fix it. Interesting use case. It's not in the document however, which you do have is. After receiving this address registration request, the address registration server MUST register the requested address in its address database, which may further be used by other network functions, such as DNS, network access control lists, etc. so presumably you tell the IA that it can't have an address by setting preferred-lifetime and valid-lifetime fields to 0, that doens't seem like an extremely useful message to send back out a client trying to register an address. Fundamentally if you don't control the network you shouldn't be managing address selection on it since you don't know what people will attach. if you do then by all means do so. > Best regards, > > Sheng > >>> Best regards, >>> >>> Sheng >>> >>>> If a strong assertion of L2 identity in support of l2/l3 bindings is >>>> required 802.1x or the wireless equivalanet seems appropiate, e.g. it's >>>> what we do today. >>>> >>>> Availing oneself of a dhcp/ra option entails a lot of signaling for what >>>> is likely a relatively ephemeral port (windows machines and macs >>>> registering privacy addresses for example). specifiying a binding >>>> lifetime seems of limited utility since the host will probably discard >>>> the address long before the lifetime expires if it's sufficently long >>>> enough to allow for long lived connections using that address. >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops > From jiangsheng@huawei.com Thu Nov 15 22:11: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 4D89721F8853; Thu, 15 Nov 2012 22:11:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 7oTNVAcyUYbi; Thu, 15 Nov 2012 22:11:55 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC3B21F8669; Thu, 15 Nov 2012 22:11:54 -0800 (PST) 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 ALP73199; Fri, 16 Nov 2012 06:11:52 +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; Fri, 16 Nov 2012 06:11:36 +0000 Received: from SZXEML460-HUB.china.huawei.com (10.82.67.203) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 16 Nov 2012 06:11:51 +0000 Received: from szxeml545-mbx.china.huawei.com ([169.254.1.6]) by szxeml460-hub.china.huawei.com ([10.82.67.203]) with mapi id 14.01.0323.003; Fri, 16 Nov 2012 14:11:45 +0800 From: Sheng Jiang To: joel jaeggli Thread-Topic: [v6ops] some feedback on http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-01 Thread-Index: AQHNw5zqb/SB0+d2NUqed+yzFK7R8pfrtqcg//+bQwCAAJFR0A== Date: Fri, 16 Nov 2012 06:11:45 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B9239F8E5CB@szxeml545-mbx.china.huawei.com> References: <50A33EFA.7070008@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8E40C@szxeml545-mbx.china.huawei.com> <50A59C1F.2040407@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8E520@szxeml545-mbx.china.huawei.com> <50A5BB8E.6010308@bogus.com> In-Reply-To: <50A5BB8E.6010308@bogus.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.140] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "dhcwg@ietf.org" , IPv6 Ops WG , "draft-ietf-dhc-addr-registration@tools.ietf.org" Subject: Re: [dhcwg] [v6ops] some feedback on http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-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, 16 Nov 2012 06:11:56 -0000 Pj4+PkluIHJlYWxpdHksIG1hbGljaW91cyBob3N0cyBkbyBub3QgZm9sbG93IHRoZSBSRkNzLg0K Pj4+IHVudHJ1c3R3b3J0aHkgaG9zdHMgYXJlbid0IG5lY2Vzc2FyaWx5IG1hbGljaW91cy4NCj4+ IE9rLiBMZXQncyBkaXNjdXNzIHdoaWNoIHBhcnQgeW91IGRvbid0IHRydXN0IGZyb20gaG9zdHMu IFRoZXJlIGFyZSBzZXZlcmFsDQo+PnBvc3NpYmlsaXRpZXMgSSBjYW4gdGhpbmsgb3V0OiBhKSBo b3N0cyByZWZ1c2UgdG8gcmVnaXN0ZXIgdGhlaXIgYWRkcmVzc2VzLCBiKSBob3N0cw0KPj5yZWdp c3RlciB3cm9uZyBhZGRyZXNzL21hYyBvbiBwdXJwb3NlDQoNCj5XaGF0IGlzIHdyb25nIE1BQyBp biB0aGlzIGNhc2U/IA0KDQpJIHJlZmVycmVkIHRvIHRoZXNlIG1hbGljaW91cyBob3N0cywgd2hv IHVzZXMgZmFrZWQgTUFDIHRvIGdldCBuZXR3b3JrIGFjY2VzcyBvciBwbGF5cyB0byBiZSBvdGhl ciBob3N0cy4NCg0KPk1BQ3MgYXJlIGdlbmVyYWxseSBidXQgbm90IGFsd2F5cyBzdGFibGUNCj4o dnJycDYgaXMgYSBwcmV0dHkgZ29vZCBjYXNlIGZvciBub3Qgc3RhYmxlKSwgaW4gYW55IGV2ZW50 IHRoZXkgYXJlDQo+cmVjb25maWd1cmFibGUuIEEgTUFDIGlzIGEgbGF5ZXIgMiBiaW5kaW5nIGFu ZCBpZiB5b3UgaGF2ZSBhIHN0cm9uZw0KPmxheWVyLTIgYXV0aGVudGljYXRpb24gKGFzIHNvbWUg Y2VudHJhbGx5IG1hbmFnZWQgbmV0d29ya3MgZG8pIHRoZW4NCj5mb3JnZXJ5IGlzIGVzc2VudGlh bGx5IGlycmVsdmFudC4gYmV5b25kIHRoYXQgdGhlIGNvcnJlY3RuZXNzIG9mIGEgTUFDDQo+YWJz ZW50IEFDTHMsIGlzIGxpbWl0ZWQgdG8gaXQncyBwcmVzZW5jZSBpbiB0aGUgYnJpZGdlIHRhYmxl IGFuZCBhbnkNCj5sMi9sMyBiaW5kaW5ncyBpdCBtYXkgaGF2ZS4NCg0KVGhlbiwgd2h5IGhvc3Rz IGFyZSB1bnRydXN0d29ydGh5IHRvIHJlZ2lzdGVyIGFkZHJlc3M/DQoNCj4+PiBJIGNhbiB3aXRo IHJlbGF0aXZlbHkgbWlub3IgZWZmb3J0IG9uIHRoZSBwYXJ0IG9mIGEgdmVuZG9yIGNhcHR1cmUg dGhlDQo+Pj4gc2FtZSBpbmZvcm1hdGlvbiwgd2l0aCBhIGxvdCBsZXNzIHNpZ25hbGluZyBvdXQg b2YgdGhlIE5EUCBjYWNoZSBvbiBteQ0KPj4+IHJvdXRlcnMsIGFuZCBkbyBzbyB3aXRob3V0IGNv bnNpZGVyYXRpb24gb2YgaG9zdHMgYmVoYXZpb3IuDQo+PiBJIGFncmVlIHdpdGggeW91IGlmIHdl IG9ubHkgZGlzY3VzcyB0aGUgc2NlbmFyaW8gdGhhdCBmaXJzdC1ob3Agcm91dGVyIGlzIGZ1bGx5 DQo+PnVuZGVyIG1hbmFnZW1lbnQgYnkgSVNQcy4gQnV0IHRoZXJlIGFyZSBvdGhlciBzY2VuYXJp b3MsIGluIHdoaWNoIGZpcnN0LWhvcA0KPj5yb3V0ZXIgaXMgaG9tZSBnYXRld2F5LCBtb2JpbGUg bm9kZSBhbmQgb3RoZXJzLiBGb3IgdGhlc2Ugc2NlbmFyaW9zLCBJU1ANCj4+Y2Fubm90IGdldCB0 aGUgYWRkcmVzcyBpbmZvcm1hdGlvbiB1bmxlc3MgaG9zdCByZWdpc3RlcmluZy4NCg0KPkVpdGhl ciB0aGUgbmV0d29yayBpcyBjZW50cmFsbHkgbWFuYWdlZCBvciBpdCBpc24ndC4gVGhlIGRyYWZ0 IGRlc2NyaWJlcw0KPmEgbWFuYWdlbWVudCBlbnRpdHkgKGVudGVycHJpc2UpIHdoaWNoIGlzIGZ1 bGx5IGluIGNvbnRyb2wgb2YgdGhlIGZpcnN0DQo+aG9wIHJvdXRlcihzKS4gSGVyZSB5b3UncmUg ZGVzY3JpYmluZyBhIHRyYW5zaXRvcnkgdHJ1c3QgbW9kZWwgd2hlcmUgbXkNCj5maXJzdCBob3Ag cm91dGVyIG1hbmFnZWQgYnkgbWUgcGFzc2VzIGEgcmVnaXN0cmF0aW9uIG9wdGlvbiB0byBteSBo b3N0cw0KPnRvIHJlZ2lzdGVyIGFkZHJlc3NlcyB1c2VkIG9uIG15IG5ldHdvcmsgd2l0aCBteSBJ U1AuIFRoYXQncyBub3QsIGluDQo+eW91ciBkb2N1bWVudC4NCg0KWWVzLCBpdCB3YXMgbm90IGlu IHRoZSBkb2N1bWVudC4gU2luY2UgdGhpcyBkb2N1bWVudCBpcyBhIERIQyBkcmFmdCwgd2UgZm9j dXNlZCBvbiB0aGUgREhDUCBQcm90b2NvbCBpbnRlcmFjdGlvbiBhbmQgb3B0aW9uIGRlZmluaXRp b24uIFdlIGRpZCBub3QgZG8gdmVyeSB3ZWxsIHRvIGRlc2NyaWJlIHN1aXRhYmxlIHNjZW5hcmlv cyB1bnRpbCByZWNlbnRseS4gV2Ugd2lsbCB3b3JrIG9uIHRoYXQuIFRoYW5rcyB0byBoZWxwIHVz IGltcHJvdmUgdGhlIGRvY3VtZW50Lg0KDQo+VGhlIG5ldHdvcmsgaW4gbXkgaG91c2UsIG9yIG15 IGVudGVycHJpc2UgaXMgbWFuYWdlZCBieSBtZSwgbXkgSVNQIG9uY2UNCj50aGV5J3ZlIGFzc2ln bmVkIG9yIGRlbGVnYXRlZCBhIHByZWZpeCBkb2Vzbid0IGdldCB0byBkZXRlcm1pbmUgaWYgSSBj YW4NCj51c2UgYW4gYWRkcmVzcyBvciBub3QuIEl0IGlzIG5vIGJ1c2luZXNzIG9mIG15IElTUCwg aWYgbXkgZnJpZGdlLCBvcg0KPnRoZXJtb3N0YXQgZGVjaWRlcyB0byB1c2UgU0xBQUMgdG8gYXNz aWduIGFuIGFkZHJlc3MgZnJvbSB0aGUgcHJlZml4DQo+d2hpY2ggaXQgcGxhbnMgdG8gdXNlIGJl Y3Vhc2UgaXQncyBjb3ZlcmVkIGJ5IFJBLg0KPg0KPj4gQW5vdGhlciBwb2ludCBpcyB0aGlzIG5l dyByZWdpc3RyYXRpb24gaXMgYmktZGlyZWN0aW9uIGludGVyYWN0aW9uLiBJdCBnaXZlcyBJU1Bz DQo+PmEgY2hhbmNlIHRvIG1hbmFnZSB0aGVzZSBob3N0LWdlbmVyYXRlZCBhZGRyZXNzZXMsIHN1 Y2ggYXMgZGVueWluZyBjZXJ0YWluDQo+PmFkZHJlc3MgKHN1Y2ggYXMgbG93IHNlYy12YWx1ZSBD R0EpLCBldGMuIEZvciBub3csIElTUHMgaGFzIHRvIGFjY2VwdCBhbGwNCj4+aG9zdC1nZW5lcmF0 ZWQgYWRkcmVzc2VzLiBJZiBJU1AgZGVuaWVzIGFjY2VzcyBiZWNhdXNlIG9mIGFueQ0KPj5hZGRy ZXNzLXJlbGV2YW50IHJlYXNvbnMsIHRoZXJlIGlzIG5vIG1lY2hhbmlzbSB0byB0ZWxsIGhvc3Rz IHdoeSBhbmQgaG93IHRvDQo+PmZpeCBpdC4NCg0KPkludGVyZXN0aW5nIHVzZSBjYXNlLiBJdCdz IG5vdCBpbiB0aGUgZG9jdW1lbnQgaG93ZXZlciwgd2hpY2ggeW91IGRvDQo+aGF2ZSBpcy4NCj4N Cj4gICAgQWZ0ZXIgcmVjZWl2aW5nIHRoaXMgYWRkcmVzcyByZWdpc3RyYXRpb24gcmVxdWVzdCwg dGhlIGFkZHJlc3MNCj4gICAgcmVnaXN0cmF0aW9uIHNlcnZlciBNVVNUIHJlZ2lzdGVyIHRoZSBy ZXF1ZXN0ZWQgYWRkcmVzcyBpbiBpdHMNCj4gICAgYWRkcmVzcyBkYXRhYmFzZSwgd2hpY2ggbWF5 IGZ1cnRoZXIgYmUgdXNlZCBieSBvdGhlciBuZXR3b3JrDQo+ICAgIGZ1bmN0aW9ucywgc3VjaCBh cyBETlMsIG5ldHdvcmsgYWNjZXNzIGNvbnRyb2wgbGlzdHMsIGV0Yy4NCj4NCj5zbyBwcmVzdW1h Ymx5IHlvdSB0ZWxsIHRoZSBJQSB0aGF0IGl0IGNhbid0IGhhdmUgYW4gYWRkcmVzcyBieSBzZXR0 aW5nDQo+cHJlZmVycmVkLWxpZmV0aW1lIGFuZCB2YWxpZC1saWZldGltZSBmaWVsZHMgdG8gMCwg dGhhdCBkb2Vucyd0IHNlZW0gbGlrZSBhbg0KPmV4dHJlbWVseSB1c2VmdWwgbWVzc2FnZSB0byBz ZW5kIGJhY2sgb3V0IGEgY2xpZW50IHRyeWluZyB0byByZWdpc3RlciBhbg0KPmFkZHJlc3MuDQoN CkFncmVlLCBtb3JlIGluZm9ybWF0aW9uIHNob3VsZCBiZSBwcm92aWRlZCBpbiB0aGUgY2FzZSBv ZiByZWplY3QgYWRkcmVzcy4gQWN0dWFsbHksIHRoZSBzcGVjaWZpYyBjYXNlIG9mIGRlbnlpbmcg Q0dBIHdpdGggbG93IHNlYy12YWx1ZSB3YXMgc29sdmVkIGJ5IGFub3RoZXIgZGVkaWNhdGVkIGRy YWZ0IChodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWRoYy1jZ2EtY29uZmln LWRoY3B2NikgLCBpbiB3aGljaCBhIG5ldyBESENQdjYgb3B0aW9uIGhhcyBiZWVuIGRlZmluZWQg dG8gZmVlZGJhY2sgYSByZWNvbW1lbmRlZCBTZWMgdmFsdWUuDQoNCldlIHdpbGwgaW1wcm92ZSB0 aGlzIHBhcnQgaW4gbmV4dCB1cGRhdGUuDQoNCkJlc3QgcmVnYXJkcywNCg0KU2hlbmcNCg0KPkZ1 bmRhbWVudGFsbHkgaWYgeW91IGRvbid0IGNvbnRyb2wgdGhlIG5ldHdvcmsgeW91IHNob3VsZG4n dCBiZSBtYW5hZ2luZw0KPmFkZHJlc3Mgc2VsZWN0aW9uIG9uIGl0IHNpbmNlIHlvdSBkb24ndCBr bm93IHdoYXQgcGVvcGxlIHdpbGwgYXR0YWNoLiBpZg0KPnlvdSBkbyB0aGVuIGJ5IGFsbCBtZWFu cyBkbyBzby4NCj4NCj4NCj4+IEJlc3QgcmVnYXJkcywNCj4+DQo+PiBTaGVuZw0KPj4NCj4+Pj4g QmVzdCByZWdhcmRzLA0KPj4+Pg0KPj4+PiBTaGVuZw0KPj4+Pg0KPj4+Pj4gSWYgYSBzdHJvbmcg YXNzZXJ0aW9uIG9mIEwyIGlkZW50aXR5IGluIHN1cHBvcnQgb2YgbDIvbDMgYmluZGluZ3MgaXMN Cj4+Pj4+IHJlcXVpcmVkIDgwMi4xeCBvciB0aGUgd2lyZWxlc3MgZXF1aXZhbGFuZXQgc2VlbXMg YXBwcm9waWF0ZSwgZS5nLiBpdCdzDQo+Pj4+PiB3aGF0IHdlIGRvIHRvZGF5Lg0KPj4+Pj4NCj4+ Pj4+IEF2YWlsaW5nIG9uZXNlbGYgb2YgYSBkaGNwL3JhIG9wdGlvbiBlbnRhaWxzIGEgbG90IG9m IHNpZ25hbGluZyBmb3Igd2hhdA0KPj4+Pj4gaXMgbGlrZWx5IGEgcmVsYXRpdmVseSBlcGhlbWVy YWwgcG9ydCAod2luZG93cyBtYWNoaW5lcyBhbmQgbWFjcw0KPj4+Pj4gcmVnaXN0ZXJpbmcgcHJp dmFjeSBhZGRyZXNzZXMgZm9yIGV4YW1wbGUpLiBzcGVjaWZpeWluZyBhIGJpbmRpbmcNCj4+Pj4+ IGxpZmV0aW1lIHNlZW1zIG9mIGxpbWl0ZWQgdXRpbGl0eSBzaW5jZSB0aGUgaG9zdCB3aWxsIHBy b2JhYmx5IGRpc2NhcmQNCj4+Pj4+IHRoZSBhZGRyZXNzIGxvbmcgYmVmb3JlIHRoZSBsaWZldGlt ZSBleHBpcmVzIGlmIGl0J3Mgc3VmZmljZW50bHkgbG9uZw0KPj4+Pj4gZW5vdWdoIHRvIGFsbG93 IGZvciBsb25nIGxpdmVkIGNvbm5lY3Rpb25zIHVzaW5nIHRoYXQgYWRkcmVzcy4NCj4+Pj4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+PiB2Nm9w cyBtYWlsaW5nIGxpc3QNCj4+Pj4+IHY2b3BzQGlldGYub3JnDQo+Pj4+PiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo+Pg0KDQo= From stenc@s-carlsen.dk Fri Nov 16 01:37: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 B9E3F21F8715 for ; Fri, 16 Nov 2012 01:37:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.989 X-Spam-Level: X-Spam-Status: No, score=-0.989 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DK=1.009, HTML_MESSAGE=0.001, J_CHICKENPOX_13=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 TcrFJ0toMmTQ for ; Fri, 16 Nov 2012 01:37:01 -0800 (PST) Received: from mail2.s-carlsen.dk (0134100024.0.fullrate.dk [90.185.128.210]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB0721F86E3 for ; Fri, 16 Nov 2012 01:37:01 -0800 (PST) Received: from silver3airport.s-carlsen.dk (unknown [IPv6:2001:16d8:dd00:81ac:5ab0:35ff:fe78:122b]) by mail2.s-carlsen.dk (Postfix) with ESMTPA id 4F704FAFA for ; Fri, 16 Nov 2012 10:36:55 +0100 (CET) Message-ID: <50A60934.5090507@s-carlsen.dk> Date: Fri, 16 Nov 2012 10:36:52 +0100 From: Sten Carlsen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: dhcwg@ietf.org References: <50A33EFA.7070008@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8E40C@szxeml545-mbx.china.huawei.com> <50A59C1F.2040407@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8E520@szxeml545-mbx.china.huawei.com> <50A5BB8E.6010308@bogus.com> In-Reply-To: <50A5BB8E.6010308@bogus.com> X-Enigmail-Version: 1.4.5 Content-Type: multipart/alternative; boundary="------------060808060102030902080302" Subject: Re: [dhcwg] [v6ops] some feedback on http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-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, 16 Nov 2012 09:37:02 -0000 This is a multi-part message in MIME format. --------------060808060102030902080302 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 16/11/12 5:05, joel jaeggli wrote: > On 11/15/12 6:33 PM, Sheng Jiang wrote: I agree with you if we only > discuss the scenario that first-hop router is fully under management > by ISPs. But there are other scenarios, in which first-hop router is > home gateway, mobile node and others. For these scenarios, ISP cannot > get the address information unless host registering. > Either the network is centrally managed or it isn't. The draft > describes a management entity (enterprise) which is fully in control > of the first hop router(s). Here you're describing a transitory trust > model where my first hop router managed by me passes a registration > option to my hosts to register addresses used on my network with my > ISP. That's not, in your document. > > The network in my house, or my enterprise is managed by me, my ISP > once they've assigned or delegated a prefix doesn't get to determine > if I can use an address or not. It is no business of my ISP, if my > fridge, or thermostat decides to use SLAAC to assign an address from > the prefix which it plans to use becuase it's covered by RA. I believe this is a very important issue. I have been following this list for some time now but have not had the time to really read all the drafts, so please allow me to take a more high level look. My understanding from most of the discussions have been that a monolithic network management style has been in the minds of the writers, however as IPv6 will be deployed generally the management must have a kind of division point as mentioned above. The ISP delegates the prefix but all management of this, including registration of hosts into DNS must be controlled locally. I.e. company XYZ using ISP ABC should be able to have all their hosts registered as xx.XYZ.tld, not as xx.ABC.tld. Specially no issue should arise from switching ISP, only the prefix should change, DNS might be hosted someplace else, maybe at the head office. This leads to my question: is this setup taken into account presently? Is there a clear cut in the system allowing for this division. I should be able to read this myself but time has not allowed for that and I have not seen this in the discussions. >> Another point is this new registration is bi-direction interaction. >> It gives ISPs a chance to manage these host-generated addresses, such >> as denying certain address (such as low sec-value CGA), etc. For now, >> ISPs has to accept all host-generated addresses. If ISP denies access >> because of any address-relevant reasons, there is no mechanism to >> tell hosts why and how to fix it. > Interesting use case. It's not in the document however, which you do > have is. > > After receiving this address registration request, the address > registration server MUST register the requested address in its > address database, which may further be used by other network > functions, such as DNS, network access control lists, etc. > > so presumably you tell the IA that it can't have an address by > setting preferred-lifetime and valid-lifetime fields to 0, that > doens't seem like an extremely useful message to send back out a > client trying to register an address. > > > Fundamentally if you don't control the network you shouldn't be > managing address selection on it since you don't know what people will > attach. if you do then by all means do so. > > >> Best regards, >> >> Sheng >> >>>> Best regards, >>>> >>>> Sheng >>>> >>>>> If a strong assertion of L2 identity in support of l2/l3 bindings is >>>>> required 802.1x or the wireless equivalanet seems appropiate, e.g. >>>>> it's >>>>> what we do today. >>>>> >>>>> Availing oneself of a dhcp/ra option entails a lot of signaling >>>>> for what >>>>> is likely a relatively ephemeral port (windows machines and macs >>>>> registering privacy addresses for example). specifiying a binding >>>>> lifetime seems of limited utility since the host will probably >>>>> discard >>>>> the address long before the lifetime expires if it's sufficently long >>>>> enough to allow for long lived connections using that address. >>>>> _______________________________________________ >>>>> v6ops mailing list >>>>> v6ops@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/v6ops >> > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg -- Best regards Sten Carlsen No improvements come from shouting: "MALE BOVINE MANURE!!!" --------------060808060102030902080302 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 16/11/12 5:05, joel jaeggli wrote:
On 11/15/12 6:33 PM, Sheng Jiang wrote: I agree with you if we only discuss the scenario that first-hop router is fully under management by ISPs. But there are other scenarios, in which first-hop router is home gateway, mobile node and others. For these scenarios, ISP cannot get the address information unless host registering.
Either the network is centrally managed or it isn't. The draft describes a management entity (enterprise) which is fully in control of the first hop router(s). Here you're describing a transitory trust model where my first hop router managed by me passes a registration option to my hosts to register addresses used on my network with my ISP. That's not, in your document.

The network in my house, or my enterprise is managed by me, my ISP once they've assigned or delegated a prefix doesn't get to determine if I can use an address or not. It is no business of my ISP, if my fridge, or thermostat decides to use SLAAC to assign an address from the prefix which it plans to use becuase it's covered by RA.
I believe this is a very important issue. I have been following this list for some time now but have not had the time to really read all the drafts, so please allow me to take a more high level look.

My understanding from most of the discussions have been that a monolithic network management style has been in the minds of the writers, however as IPv6 will be deployed generally the management must have a kind of division point as mentioned above. The ISP delegates the prefix but all management of this, including registration of hosts into DNS must be controlled locally. I.e. company XYZ using ISP ABC should be able to have all their hosts registered as xx.XYZ.tld, not as xx.ABC.tld. Specially no issue should arise from switching ISP, only the prefix should change, DNS might be hosted someplace else, maybe at the head office.

This leads to my question: is this setup taken into account presently? Is there a clear cut in the system allowing for this division.  I should be able to read this myself but time has not allowed for that and I have not seen this in the discussions.
Another point is this new registration is bi-direction interaction. It gives ISPs a chance to manage these host-generated addresses, such as denying certain address (such as low sec-value CGA), etc. For now, ISPs has to accept all host-generated addresses. If ISP denies access because of any address-relevant reasons, there is no mechanism to tell hosts why and how to fix it.
Interesting use case. It's not in the document however, which you do have is.

   After receiving this address registration request, the address
   registration server MUST register the requested address in its
   address database, which may further be used by other network
   functions, such as DNS, network access control lists, etc.

so presumably you tell the IA that it can't have an address by  setting preferred-lifetime and valid-lifetime fields to 0, that doens't seem like an extremely useful message to send back out a client trying to register an address.


Fundamentally if you don't control the network you shouldn't be managing address selection on it since you don't know what people will attach. if you do then by all means do so.


Best regards,

Sheng

Best regards,

Sheng

If a strong assertion of L2 identity in support of l2/l3 bindings is
required 802.1x or the wireless equivalanet seems appropiate, e.g. it's
what we do today.

Availing oneself of a dhcp/ra option entails a lot of signaling for what
is likely a relatively ephemeral port (windows machines and macs
registering privacy addresses for example). specifiying a binding
lifetime seems of limited utility since the host will probably discard
the address long before the lifetime expires if it's sufficently long
enough to allow for long lived connections using that address.
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops


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

-- 
Best regards

Sten Carlsen

No improvements come from shouting:
       "MALE BOVINE MANURE!!!"
--------------060808060102030902080302-- From roberta.maglione@telecomitalia.it Fri Nov 16 01:41: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 0C92721F8562 for ; Fri, 16 Nov 2012 01:41:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.145 X-Spam-Level: X-Spam-Status: No, score=-1.145 tagged_above=-999 required=5 tests=[AWL=0.574, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, 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 QCFIXFHKfZ9G for ; Fri, 16 Nov 2012 01:41:18 -0800 (PST) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by ietfa.amsl.com (Postfix) with ESMTP id 118EF21F8A3A for ; Fri, 16 Nov 2012 01:41:18 -0800 (PST) Received: from grfhub704ba020.griffon.local (10.188.101.117) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.3.279.5; Fri, 16 Nov 2012 10:41:15 +0100 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by grfhub704ba020.griffon.local ([10.188.101.117]) with mapi; Fri, 16 Nov 2012 10:41:15 +0100 From: Maglione Roberta To: 'Leaf yeh' , " WG" Date: Fri, 16 Nov 2012 10:41:15 +0100 Thread-Topic: WGLC: draft-ietf-dhc-dhcpv6-radius-opt-04 Thread-Index: AQHNwnuJXxc1SNgKKEqdICsCoFzJ1ZfqqxqwgAEHqaCAAIT1gA== Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE519AC44BE9@GRFMBX704BA020.griffon.local> References: <8D23D4052ABE7A4490E77B1A012B630747405925@mbx-01.win.nominum.com> <282BBE8A501E1F4DA9C775F964BB21FE519AC44BE1@GRFMBX704BA020.griffon.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 'Ted Lemon' Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-radius-opt-04 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 09:41:19 -0000 Ok, but replace "Attribute" with " Attributes" Roberta -----Original Message----- From: Leaf yeh [mailto:leaf.y.yeh@huawei.com]=20 Sent: Friday, November 16, 2012 3:23 AM To: Maglione Roberta; WG Cc: 'Ted Lemon'; mohamed.boucadair@orange.com Subject: RE: WGLC: draft-ietf-dhc-dhcpv6-radius-opt-04 Roberta - I would suggest adding at the end "additional attributes may be a= dded to this list in future according to new RADIUS attributes specificatio= ns" The following text in section 9, IANA consideration, ' The RADIUS Attribute may be added to this list after IETF Review [RFC5= 226].'=20 could be updated to be 'New RADIUS Attribute may be added to this list after Expert Review [RFC= 5226].' How about to copy the same sentence into section 4, DHCPv6 RADIUS option? = =20 It sounds more smooth than the above text '...added to this list in future = according to new RADIUS attributes specifications ' to me. I definitely sup= port the new draft-ietf or RFC with the definition of new RADIUS attribute,= would suggest the potential expert review for the adding into the new IANA= Registry of 'RADIUS Attributes Permitted in the DHCPv6 RADIUS option'. Best Regards, Leaf -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of M= aglione Roberta Sent: Thursday, November 15, 2012 6:06 PM To: 'Ted Lemon'; WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-radius-opt-04 Hello, I have read the draft and I support this work. I have a comment: Section 4 says: " The RADIUS attributes listed in the below table are recom= mended as the first batch of attributes in the IANA Registry of 'RADIUS Attributes Permitted in the DHCPv6 RADIUS option'" I would suggest adding at the end "additional attributes may be added to this list in future according to new= RADIUS attributes specifications" A part from that I am in favor of advancing this draft. Regards Roberta -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= ed Lemon Sent: Wednesday, November 14, 2012 4:20 PM To: WG Subject: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-radius-opt-04 The authors of this document have requested a working group last call. Th= e document describes a mechanism, similar to the mechanism in DHCPv4, for c= arrying RADIUS options in DHCP packets. If this is of interest to you, pl= ease review the draft: http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-radius-opt-04 If you have comments, please send them to the working group mailing list. = If you are in favor of advancing the document as it is, please reply to th= is message and say so. If you do not favor advancing the document, and do= not have specific comments, please reply to this message indicating that y= ou don't favor advancing the document. Since the document has my name on it, John will be doing the evaluation of = consensus. He will do this on or after November 28. Thanks! _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From roberta.maglione@telecomitalia.it Fri Nov 16 05:13:03 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 DB16121F8D0A; Fri, 16 Nov 2012 05:13:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.26 X-Spam-Level: X-Spam-Status: No, score=-1.26 tagged_above=-999 required=5 tests=[AWL=0.459, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, 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 EMP3KZ3+zAFn; Fri, 16 Nov 2012 05:13:03 -0800 (PST) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by ietfa.amsl.com (Postfix) with ESMTP id AA36121F8C71; Fri, 16 Nov 2012 05:13:02 -0800 (PST) Received: from grfhub704ba020.griffon.local (10.188.101.117) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.3.279.5; Fri, 16 Nov 2012 14:13:01 +0100 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by grfhub704ba020.griffon.local ([10.188.101.117]) with mapi; Fri, 16 Nov 2012 14:13:01 +0100 From: Maglione Roberta To: 'Leaf Yeh' , "ietf@ietf.org" Date: Fri, 16 Nov 2012 14:13:00 +0100 Thread-Topic: [Softwires] Last Call: (RADIUS Attribute for 6rd) to Proposed Standard Thread-Index: Ac3Dea+1vtvDT4NuRzq0ZZgefRaMjQAfhzhgAADf3CA= Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE519AC44BEA@GRFMBX704BA020.griffon.local> References: <20121115213918.3949.85119.idtracker@ietfa.amsl.com> <50a63503.848f440a.6460.6ac1@mx.google.com> In-Reply-To: <50a63503.848f440a.6460.6ac1@mx.google.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "softwires@ietf.org" , " WG" Subject: Re: [dhcwg] [Softwires] Last Call: (RADIUS Attribute for 6rd) to Proposed Standard X-BeenThere: dhcwg@ietf.org 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, 16 Nov 2012 13:13:04 -0000 Hi Leaf, > Section 3 - If the DHCP server to which the DHCP Request message was sent= > at time T1 has not responded, the DHCP client enters the REBINDING stat= e > and attempts to contact any server. > Per the Figure 5 in RFC2131, the above 'T1' sounds 'T2'. (http://www.rfc-editor.org/rfc/rfc2131.txt) Why T2? According to section 4.4.5 of RFC 2131: " At time T1 the client moves to RENEWING state and sends (via unicast) a DHCPREQUEST message to the server to extend its lease." [..] " If no DHCPACK arrives before time T2, the client moves to REBINDING state and sends (via broadcast) a DHCPREQUEST message to extend its lease." The DHCPREQUEST is sent at T1, in my opinion the current text is correct. Thanks Regards, Roberta -----Original Message----- From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Beh= alf Of Leaf Yeh Sent: Friday, November 16, 2012 1:44 PM To: ietf@ietf.org Cc: softwires@ietf.org Subject: Re: [Softwires] Last Call: (RADIUS Attribute for 6rd) to Proposed Standard Section 3 - After the BNG responds to the user with an Advertise message, the user requests for a DHCP 6rd Option by carrying a Parameter Request option (55) [RFC2132]. Per the Figure 1 in Section 3, the above 'Advertise message' sounds the DHCPv4 message of 'DHCPOFFER (2)'. (http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameter= s .xml) Section 3 - If the DHCP server to which the DHCP Request message was sent a= t time T1 has not responded, the DHCP client enters the REBINDING state and attempts to contact any server. Per the Figure 5 in RFC2131, the above 'T1' sounds 'T2'. (http://www.rfc-editor.org/rfc/rfc2131.txt) Best Regards, Leaf -----Original Message----- From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Behalf Of The IESG Sent: Friday, November 16, 2012 5:39 AM To: IETF-Announce Cc: softwires@ietf.org Subject: [Softwires] Last Call: (RADIUS Attribute for 6rd) t= o Proposed Standard The IESG has received a request from the Softwires WG (softwire) to conside= r the following document: - 'RADIUS Attribute for 6rd' 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-11-29. 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 IPv6 Rapid Deployment (6rd) is one of the most popular methods to provide both IPv4 and IPv6 connectivity services simultaneously during the IPv4/IPv6 co-existing period. The Dynamic Host Configuration Protocol (DHCP) 6rd option has been defined to configure 6rd Customer Edge (CE). However, in many networks, the configuration information may be stored in Authentication Authorization and Accounting (AAA) servers while user configuration is mainly from Broadband Network Gateway (BNG) through DHCP protocol. This document defines a Remote Authentication Dial In User Service (RADIUS) attribute that carries 6rd configuration information from AAA server to BNG. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-softwire-6rd-radius-attrib/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-softwire-6rd-radius-attrib/ballo= t / No IPR declarations have been submitted directly on this I-D. _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. From Ted.Lemon@nominum.com Fri Nov 16 05: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 91BD221F8C23; Fri, 16 Nov 2012 05:41:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.579 X-Spam-Level: X-Spam-Status: No, score=-106.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 R-o5+etsSt1w; Fri, 16 Nov 2012 05:41:00 -0800 (PST) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id AE61C21F8BA0; Fri, 16 Nov 2012 05:40:59 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKUKZCa09AH3GM28ojK8OpYcpiMl2x3fdF@postini.com; Fri, 16 Nov 2012 05:40:59 PST 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 81BF41B8056; Fri, 16 Nov 2012 05:40:58 -0800 (PST) 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 719EC190043; Fri, 16 Nov 2012 05:40:58 -0800 (PST) (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.0318.004; Fri, 16 Nov 2012 05:40:52 -0800 From: Ted Lemon To: Mark Smith Thread-Topic: [v6ops] some feedback on http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-01 Thread-Index: AQHNw8QMn+T7t8ukdkiHzcz0NllQQpfs/pEA Date: Fri, 16 Nov 2012 13:40:52 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630747408741@mbx-01.win.nominum.com> References: <50A33EFA.7070008@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8E40C@szxeml545-mbx.china.huawei.com> <50A59C1F.2040407@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8E520@szxeml545-mbx.china.huawei.com> <50A5BB8E.6010308@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8E5CB@szxeml545-mbx.china.huawei.com> <1353047488.86944.YahooMailNeo@web32501.mail.mud.yahoo.com> In-Reply-To: <1353047488.86944.YahooMailNeo@web32501.mail.mud.yahoo.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: <3FFE0540E124744A8C609D584A5FED1D@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: joel jaeggli , "dhcwg@ietf.org" , IPv6 Ops WG , "draft-ietf-dhc-addr-registration@tools.ietf.org" Subject: Re: [dhcwg] [v6ops] some feedback on http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-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, 16 Nov 2012 13:41:01 -0000 On Nov 16, 2012, at 1:31 AM, Mark Smith wrote: > I agree with Joel, I think observation by most likely a router is a bette= r method, as it will capture address information regardless of whether it w= as configured via static, SLAAC or DHCPv6 (or any future methods). It's certainly true that a router can capture all the IPv4 and IPv6 address= es that a device with a particular MAC address uses. However, what a rout= er _can't_ do, and what this option allows to be done, is for a device that= has autoconfigured to then provide the network administrator with a hint a= s to what its FQDN should be. This information isn't available to the rou= ter. It seems to me that although it is true that it is worthwhile to define a m= echanism for getting common address information from a router, this is orth= ogonal to the question of whether a client-based mechanism for address regi= stration is useful. It seems to me that there are three broad classificat= ions of use cases here: 1. In an environment where address registration is mandatory, and hosts are= tightly controlled, this protocol may suffice. 2. In an environment where address registration is optional/advisory, this = protocol may suffice, since presumably the reason you register addresses is= to track client-sourced information like hostname that relates to the addr= ess. 3. In an environment where address registration is mandatory and hosts are = not tightly controlled, you need support for address registration on the ro= uter. However, you can _still_ benefit in this case from the DHCP-based a= ddress registration protocol; devices that support it can still provide hin= ts about the FQDN they want. I point this out because the reason I support this draft is the FQDN use ca= se. This is a use case that has seen substantial use in enterprise enviro= nments in IPv4. We do not currently have a solution to the problem for IP= v6, because in IPv6 we don't require DHCP for host configuration. This DH= CP extension allows us to leverage a DHCP infrastructure without _requiring= _ that hosts autoconfigure using DHCP, and without even _requiring_ that ho= sts register their addresses at all. I think Sheng has a different use case in mind, and from what I can tell hi= s use case falls into the first category, where mine falls into the second.= I know of other enterprise users who have use cases that fall into categ= ory 3; for them, this protocol will not be sufficient, and they will need t= he router-based protocol either instead, or as well. From Ted.Lemon@nominum.com Fri Nov 16 05:45: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 1A1F621F841A for ; Fri, 16 Nov 2012 05:45:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.58 X-Spam-Level: X-Spam-Status: No, score=-106.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 qzSaCrSftKx2 for ; Fri, 16 Nov 2012 05:45:49 -0800 (PST) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by ietfa.amsl.com (Postfix) with ESMTP id 714E421F8417 for ; Fri, 16 Nov 2012 05:45:49 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKUKZDjTcYrSh0DPiO7IeUCmueDuIkLXSN@postini.com; Fri, 16 Nov 2012 05:45:49 PST 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 BF3451B8038 for ; Fri, 16 Nov 2012 05:45:48 -0800 (PST) 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 B61C2190043; Fri, 16 Nov 2012 05:45:48 -0800 (PST) (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.0318.004; Fri, 16 Nov 2012 05:45:48 -0800 From: Ted Lemon To: Sten Carlsen Thread-Topic: [dhcwg] [v6ops] some feedback on http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-01 Thread-Index: AQHNw6+nmCuwAPeW30ysErdHiWQsFJfsuo4AgABFi4A= Date: Fri, 16 Nov 2012 13:45:48 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307474087B8@mbx-01.win.nominum.com> References: <50A33EFA.7070008@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8E40C@szxeml545-mbx.china.huawei.com> <50A59C1F.2040407@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8E520@szxeml545-mbx.china.huawei.com> <50A5BB8E.6010308@bogus.com> <50A60934.5090507@s-carlsen.dk> In-Reply-To: <50A60934.5090507@s-carlsen.dk> 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: <7DDA706806764443B825615BA5C5B912@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [dhcwg] [v6ops] some feedback on http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-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, 16 Nov 2012 13:45:50 -0000 On Nov 16, 2012, at 4:36 AM, Sten Carlsen wrote: > This leads to my question: is this setup taken into account presently? Is= there a clear cut in the system allowing for this division. I should be a= ble to read this myself but time has not allowed for that and I have not se= en this in the discussions. It's a specific intent of the DHC working group that this document cover th= e DHCP/DNS update use case. It would be good if you could read the docume= nt and assure yourself that it does in fact cover that case=97more review i= s always better. From leaf.yeh.sdo@gmail.com Fri Nov 16 05:57: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 E555321F8769; Fri, 16 Nov 2012 05:57:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.669 X-Spam-Level: X-Spam-Status: No, score=-3.669 tagged_above=-999 required=5 tests=[AWL=-0.070, 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 bEiJ3z0p3ASn; Fri, 16 Nov 2012 05:57:51 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id B30CF21F8661; Fri, 16 Nov 2012 05:57:51 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id fb11so1900640pad.31 for ; Fri, 16 Nov 2012 05:57:51 -0800 (PST) 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=s9DkzeQ7c91TGu2rh5aAyXdJlulnUeUzz1AhpAk6ZyA=; b=RCZB5hJoNF6HwfKBXjoGjk9yzES1e0nGFtCEmq8zByF8k/D/dzjslvNAd698U83DqJ FZInyR2IqOdgYYZC/ZIxy8PHJimwscGmppIwBuFbfKXaYMIZ5gaRuqcZJPh036lTW6dS yjMuiSon8pe9L0KGt/I8d6eLtpZw3A+TV8set/5HvfIRuwrP1V3/xCryQBYDHssvzfK4 wD3X/EAGxjpxkREhJSq4E2Cg4vrRBGJHb+rw0cH2FlwkLtD+Gzv4i+YjDTIjokX1tEXr P00rhEqttFvQT+e06VYvajob73fiF9AenE6Rx4tbFIHczHRNJjOpCzIpJTEXc8gmSEnW gVqA== Received: by 10.68.234.201 with SMTP id ug9mr9438910pbc.63.1353074270985; Fri, 16 Nov 2012 05:57:50 -0800 (PST) Received: from lst9242355d22a ([14.153.105.155]) by mx.google.com with ESMTPS id o11sm1280720pby.8.2012.11.16.05.57.41 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 16 Nov 2012 05:57:49 -0800 (PST) From: "Leaf Yeh" To: "'Maglione Roberta'" , References: <20121115213918.3949.85119.idtracker@ietfa.amsl.com> <50a63503.848f440a.6460.6ac1@mx.google.com> <282BBE8A501E1F4DA9C775F964BB21FE519AC44BEA@GRFMBX704BA020.griffon.local> In-Reply-To: <282BBE8A501E1F4DA9C775F964BB21FE519AC44BEA@GRFMBX704BA020.griffon.local> Date: Fri, 16 Nov 2012 21:57:43 +0800 Message-ID: <50a6465d.4b53440a.7e28.73cc@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: Ac3Dea+1vtvDT4NuRzq0ZZgefRaMjQAfhzhgAADf3CAAARUoIA== Content-Language: zh-cn Cc: softwires@ietf.org, dhcwg@ietf.org Subject: Re: [dhcwg] [Softwires] Last Call: (RADIUS Attribute for 6rd) to Proposed Standard X-BeenThere: dhcwg@ietf.org 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, 16 Nov 2012 13:57:53 -0000 According to section 4.4.5 of RFC 2131: " At time T1 the client moves to RENEWING state and sends (via unicast) a DHCPREQUEST message to the server to extend its lease." [..] " If no DHCPACK arrives before time T2, the client moves to REBINDING state and sends (via broadcast) a DHCPREQUEST message to extend its lease." The DHCPREQUEST is sent at T1, in my opinion the current text is correct. Correct but not accurate. The client enters the rebinding state after T2 expired. How about to update the text to be 'If the DHCP server has not replied the DHCPREQUEST message till T2, the DHCP client enters into the REBINDING state and attempts to contact any possible server. '? Best Regards, Leaf -----Original Message----- From: Maglione Roberta [mailto:roberta.maglione@telecomitalia.it] Sent: Friday, November 16, 2012 9:13 PM To: 'Leaf Yeh'; ietf@ietf.org Cc: softwires@ietf.org; WG Subject: RE: [Softwires] Last Call: (RADIUS Attribute for 6rd) to Proposed Standard Hi Leaf, > Section 3 - If the DHCP server to which the DHCP Request message was sent > at time T1 has not responded, the DHCP client enters the REBINDING state > and attempts to contact any server. > Per the Figure 5 in RFC2131, the above 'T1' sounds 'T2'. (http://www.rfc-editor.org/rfc/rfc2131.txt) Why T2? According to section 4.4.5 of RFC 2131: " At time T1 the client moves to RENEWING state and sends (via unicast) a DHCPREQUEST message to the server to extend its lease." [..] " If no DHCPACK arrives before time T2, the client moves to REBINDING state and sends (via broadcast) a DHCPREQUEST message to extend its lease." The DHCPREQUEST is sent at T1, in my opinion the current text is correct. Thanks Regards, Roberta -----Original Message----- From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Behalf Of Leaf Yeh Sent: Friday, November 16, 2012 1:44 PM To: ietf@ietf.org Cc: softwires@ietf.org Subject: Re: [Softwires] Last Call: (RADIUS Attribute for 6rd) to Proposed Standard Section 3 - After the BNG responds to the user with an Advertise message, the user requests for a DHCP 6rd Option by carrying a Parameter Request option (55) [RFC2132]. Per the Figure 1 in Section 3, the above 'Advertise message' sounds the DHCPv4 message of 'DHCPOFFER (2)'. (http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters .xml) Section 3 - If the DHCP server to which the DHCP Request message was sent at time T1 has not responded, the DHCP client enters the REBINDING state and attempts to contact any server. Per the Figure 5 in RFC2131, the above 'T1' sounds 'T2'. (http://www.rfc-editor.org/rfc/rfc2131.txt) Best Regards, Leaf -----Original Message----- From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Behalf Of The IESG Sent: Friday, November 16, 2012 5:39 AM To: IETF-Announce Cc: softwires@ietf.org Subject: [Softwires] Last Call: (RADIUS Attribute for 6rd) to Proposed Standard The IESG has received a request from the Softwires WG (softwire) to consider the following document: - 'RADIUS Attribute for 6rd' 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-11-29. 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 IPv6 Rapid Deployment (6rd) is one of the most popular methods to provide both IPv4 and IPv6 connectivity services simultaneously during the IPv4/IPv6 co-existing period. The Dynamic Host Configuration Protocol (DHCP) 6rd option has been defined to configure 6rd Customer Edge (CE). However, in many networks, the configuration information may be stored in Authentication Authorization and Accounting (AAA) servers while user configuration is mainly from Broadband Network Gateway (BNG) through DHCP protocol. This document defines a Remote Authentication Dial In User Service (RADIUS) attribute that carries 6rd configuration information from AAA server to BNG. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-softwire-6rd-radius-attrib/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-softwire-6rd-radius-attrib/ballot / No IPR declarations have been submitted directly on this I-D. _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. From roberta.maglione@telecomitalia.it Fri Nov 16 06:09:18 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 03B3921F8590; Fri, 16 Nov 2012 06:09:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.336 X-Spam-Level: X-Spam-Status: No, score=-1.336 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, 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 G+Boe+t0GLHe; Fri, 16 Nov 2012 06:09:17 -0800 (PST) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by ietfa.amsl.com (Postfix) with ESMTP id 43DA221F8521; Fri, 16 Nov 2012 06:09:16 -0800 (PST) Received: from GRFHUB702BA020.griffon.local (10.188.101.112) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.3.279.5; Fri, 16 Nov 2012 15:09:13 +0100 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by GRFHUB702BA020.griffon.local ([10.188.101.112]) with mapi; Fri, 16 Nov 2012 15:09:11 +0100 From: Maglione Roberta To: 'Leaf Yeh' , 'Sheng Jiang' Date: Fri, 16 Nov 2012 15:09:11 +0100 Thread-Topic: [Softwires] Last Call: (RADIUS Attribute for 6rd) to Proposed Standard Thread-Index: Ac3Dea+1vtvDT4NuRzq0ZZgefRaMjQAfhzhgAADf3CAAARUoIAAA6biw Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE519AC44BEB@GRFMBX704BA020.griffon.local> References: <20121115213918.3949.85119.idtracker@ietfa.amsl.com> <50a63503.848f440a.6460.6ac1@mx.google.com> <282BBE8A501E1F4DA9C775F964BB21FE519AC44BEA@GRFMBX704BA020.griffon.local> <50a6465d.4b53440a.7e28.73cc@mx.google.com> In-Reply-To: <50a6465d.4b53440a.7e28.73cc@mx.google.com> Accept-Language: en-US, it-IT Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, it-IT x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "softwires@ietf.org" , "dhcwg@ietf.org" , "ietf@ietf.org" Subject: Re: [dhcwg] [Softwires] Last Call: (RADIUS Attribute for 6rd) to Proposed Standard X-BeenThere: dhcwg@ietf.org 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, 16 Nov 2012 14:09:18 -0000 Leaf, In my opinion current text is fine and inline with RFC2131, while the text = you are proposing is not completely accurate because it does not clarify "w= hich DHCP Server" has not replied. 'If the DHCP server has not replied the DHCPREQUEST message till T2, the DHCP client enters into the REBINDING stat= e and attempts to contact any possible server. ' Sheng, As original author of this text, what do you think? Thanks, Roberta -----Original Message----- From: Leaf Yeh [mailto:leaf.yeh.sdo@gmail.com] Sent: Friday, November 16, 2012 2:58 PM To: Maglione Roberta; ietf@ietf.org Cc: softwires@ietf.org; dhcwg@ietf.org Subject: RE: [Softwires] Last Call: (RADIUS Attribute for 6rd) to Proposed Standard According to section 4.4.5 of RFC 2131: " At time T1 the client moves to RENEWING state and sends (via unicast) a DHCPREQUEST message to the server to extend its lease." [..] " If no DHCPACK arrives before time T2, the client moves to REBINDING state and sends (via broadcast) a DHCPREQUEST message to extend its lease." The DHCPREQUEST is sent at T1, in my opinion the current text is correct. Correct but not accurate. The client enters the rebinding state after T2 expired. How about to update the text to be 'If the DHCP server has not replied the DHCPREQUEST message till T2, the DHCP client enters into the REBINDING stat= e and attempts to contact any possible server. '? Best Regards, Leaf -----Original Message----- From: Maglione Roberta [mailto:roberta.maglione@telecomitalia.it] Sent: Friday, November 16, 2012 9:13 PM To: 'Leaf Yeh'; ietf@ietf.org Cc: softwires@ietf.org; WG Subject: RE: [Softwires] Last Call: (RADIUS Attribute for 6rd) t= o Proposed Standard Hi Leaf, > Section 3 - If the DHCP server to which the DHCP Request message was sent > at time T1 has not responded, the DHCP client enters the REBINDING state > and attempts to contact any server. > Per the Figure 5 in RFC2131, the above 'T1' sounds 'T2'. (http://www.rfc-editor.org/rfc/rfc2131.txt) Why T2? According to section 4.4.5 of RFC 2131: " At time T1 the client moves to RENEWING state and sends (via unicast) a DHCPREQUEST message to the server to extend its lease." [..] " If no DHCPACK arrives before time T2, the client moves to REBINDING state and sends (via broadcast) a DHCPREQUEST message to extend its lease." The DHCPREQUEST is sent at T1, in my opinion the current text is correct. Thanks Regards, Roberta -----Original Message----- From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Behalf Of Leaf Yeh Sent: Friday, November 16, 2012 1:44 PM To: ietf@ietf.org Cc: softwires@ietf.org Subject: Re: [Softwires] Last Call: (RADIUS Attribute for 6rd) t= o Proposed Standard Section 3 - After the BNG responds to the user with an Advertise message, the user requests for a DHCP 6rd Option by carrying a Parameter Request option (55) [RFC2132]. Per the Figure 1 in Section 3, the above 'Advertise message' sounds the DHCPv4 message of 'DHCPOFFER (2)'. (http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameter= s .xml) Section 3 - If the DHCP server to which the DHCP Request message was sent a= t time T1 has not responded, the DHCP client enters the REBINDING state and attempts to contact any server. Per the Figure 5 in RFC2131, the above 'T1' sounds 'T2'. (http://www.rfc-editor.org/rfc/rfc2131.txt) Best Regards, Leaf -----Original Message----- From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Behalf Of The IESG Sent: Friday, November 16, 2012 5:39 AM To: IETF-Announce Cc: softwires@ietf.org Subject: [Softwires] Last Call: (RADIUS Attribute for 6rd) t= o Proposed Standard The IESG has received a request from the Softwires WG (softwire) to conside= r the following document: - 'RADIUS Attribute for 6rd' 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-11-29. 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 IPv6 Rapid Deployment (6rd) is one of the most popular methods to provide both IPv4 and IPv6 connectivity services simultaneously during the IPv4/IPv6 co-existing period. The Dynamic Host Configuration Protocol (DHCP) 6rd option has been defined to configure 6rd Customer Edge (CE). However, in many networks, the configuration information may be stored in Authentication Authorization and Accounting (AAA) servers while user configuration is mainly from Broadband Network Gateway (BNG) through DHCP protocol. This document defines a Remote Authentication Dial In User Service (RADIUS) attribute that carries 6rd configuration information from AAA server to BNG. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-softwire-6rd-radius-attrib/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-softwire-6rd-radius-attrib/ballo= t / No IPR declarations have been submitted directly on this I-D. _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intende= d recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. From stenc@s-carlsen.dk Fri Nov 16 10:28: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 270C721F8AEA for ; Fri, 16 Nov 2012 10:28:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.289 X-Spam-Level: X-Spam-Status: No, score=-1.289 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_DK=1.009, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FjpF7EQnH1CO for ; Fri, 16 Nov 2012 10:28:44 -0800 (PST) Received: from mail2.s-carlsen.dk (0134100024.0.fullrate.dk [90.185.128.210]) by ietfa.amsl.com (Postfix) with ESMTP id 4415821F8A67 for ; Fri, 16 Nov 2012 10:28:44 -0800 (PST) Received: from silver4-wire.s-carlsen.dk (unknown [IPv6:2001:16d8:dd00:81ac:cabc:c8ff:fe91:1152]) by mail2.s-carlsen.dk (Postfix) with ESMTPA id 62A85EB24; Fri, 16 Nov 2012 19:28:40 +0100 (CET) Message-ID: <50A685D7.5030507@s-carlsen.dk> Date: Fri, 16 Nov 2012 19:28:39 +0100 From: Sten Carlsen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Ted Lemon References: <50A33EFA.7070008@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8E40C@szxeml545-mbx.china.huawei.com> <50A59C1F.2040407@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8E520@szxeml545-mbx.china.huawei.com> <50A5BB8E.6010308@bogus.com> <50A60934.5090507@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B6307474087B8@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307474087B8@mbx-01.win.nominum.com> Content-Type: multipart/alternative; boundary="------------040107040701080803010807" Cc: "" Subject: Re: [dhcwg] [v6ops] some feedback on http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-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, 16 Nov 2012 18:28:52 -0000 This is a multi-part message in MIME format. --------------040107040701080803010807 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit I see this document is really describing a tightly controlled setup, whereas I was looking for a kind of two-tier management setup. I was concerned with how it would work in the following setup: Internet --a-- ISP --b-- SOHO --c-- a number of hosts In link "a" the ISP is given a large address area from IANA one or more /48 prefixes. In link "b" the ISP hands one /64 prefix on to a small company, (SOHO) these addresses should be given out to the various hosts in the SOHO network and their names/IPs should be registered in the SOHO's own DNS and not be registered in the ISP's DNS but potentially in the router access tables to be allowed out. Link "c" is the SOHO internal network, this should be controlled solely by the SOHO. So given my level of understanding here I would like to ask where you see this draft used? 1 - Is it used by the ISP to control the SOHO hosts, I think that is not a good solution. 2 - Is it used by the SOHO to control his own hosts, that would be fine, except if the ISP needs to know which hosts are allowed to access the internet. 3 - Is it used on link "b" only to control the router at the edge of the SOHO and keep track of the ISPs own network units? I believe #3 on my list is the best place to use this new capability, #2 is also very much in line with the goals and intentions of a well managed SOHO. From my reading it looks like is is much more geared towards #1, which I feel would be a big mistake. It would prevent the SOHO from actually managing their own hosts. As mentioned before I can easily have missed one point here or maybe this document is not suited to be used in this situation but some other document is written to cover this situation. I found a language problem, I believe. At the end of chapter 3 I find this paragraph, which I think needs a bit tweaking: By received the acknowledgement, the host can continue use the registered address. It SHOULD use the assigned preferred and valid lifetime for the correspondeding address. On 16/11/12 14:45, Ted Lemon wrote: > On Nov 16, 2012, at 4:36 AM, Sten Carlsen wrote: >> This leads to my question: is this setup taken into account presently? Is there a clear cut in the system allowing for this division. I should be able to read this myself but time has not allowed for that and I have not seen this in the discussions. > It's a specific intent of the DHC working group that this document cover the DHCP/DNS update use case. It would be good if you could read the document and assure yourself that it does in fact cover that case—more review is always better. > -- Best regards Sten Carlsen No improvements come from shouting: "MALE BOVINE MANURE!!!" --------------040107040701080803010807 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit I see this document is really describing a tightly controlled setup, whereas I was looking for a kind of two-tier management setup.

I was concerned with how it would work in the following setup:

Internet --a-- ISP --b-- SOHO --c-- a number of hosts

In link "a" the ISP is given a large address area from IANA one or more /48 prefixes.
In link "b" the ISP hands one /64 prefix on to a small company, (SOHO) these addresses should be given out to the various hosts in the SOHO network and their names/IPs should be registered in the SOHO's own DNS and not be registered in the ISP's DNS but potentially in the router access tables to be allowed out.
Link "c" is the SOHO internal network, this should be controlled solely by the SOHO.

So given my level of understanding here I would like to ask where you see this draft used?
1 - Is it used by the ISP to control the SOHO hosts, I think that is not a good solution.
2 - Is it used by the SOHO to control his own hosts, that would be fine, except if the ISP needs to know which hosts are allowed to access the internet.
3 - Is it used on link "b" only to control the router at the edge of the SOHO and keep track of the ISPs own network units?

I believe #3 on my list is the best place to use this new capability, #2 is also very much in line with the goals and intentions of a well managed SOHO.

From my reading it looks like is is much more geared towards #1, which I feel would be a big mistake. It would prevent the SOHO from actually managing their own hosts.

As mentioned before I can easily have missed one point here or maybe this document is not suited to be used in this situation but some other document is written to cover this situation.

I found a language problem, I believe. At the end of chapter 3 I find this paragraph, which I think needs a bit tweaking:

 By received the acknowledgement, the host can continue use the
   registered address.  It SHOULD use the assigned preferred and valid
   lifetime for the correspondeding address.
On 16/11/12 14:45, Ted Lemon wrote:
On Nov 16, 2012, at 4:36 AM, Sten Carlsen <stenc@s-carlsen.dk> wrote:

This leads to my question: is this setup taken into account presently? Is there a clear cut in the system allowing for this division.  I should be able to read this myself but time has not allowed for that and I have not seen this in the discussions.

It's a specific intent of the DHC working group that this document cover the DHCP/DNS update use case.   It would be good if you could read the document and assure yourself that it does in fact cover that case—more review is always better.



-- 
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!"
--------------040107040701080803010807-- From Ted.Lemon@nominum.com Fri Nov 16 10: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 4472C21F84D3 for ; Fri, 16 Nov 2012 10:51:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.581 X-Spam-Level: X-Spam-Status: No, score=-106.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 MWEn5D3UeihQ for ; Fri, 16 Nov 2012 10:51:27 -0800 (PST) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id 31C7921F8A67 for ; Fri, 16 Nov 2012 10:51:27 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKUKaLKa4eb+3n/1rI3wJv7R6IfC+o++C7@postini.com; Fri, 16 Nov 2012 10:51:27 PST 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 762E81B8120 for ; Fri, 16 Nov 2012 10:51:21 -0800 (PST) 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 6C128190043; Fri, 16 Nov 2012 10:51:21 -0800 (PST) (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.0318.004; Fri, 16 Nov 2012 10:51:21 -0800 From: Ted Lemon To: Sten Carlsen Thread-Topic: [dhcwg] [v6ops] some feedback on http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-01 Thread-Index: AQHNxCg1IRhs9GxkK0SVsthhVrQNtZftVIaA Date: Fri, 16 Nov 2012 18:51:20 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630747408DF9@mbx-01.win.nominum.com> References: <50A33EFA.7070008@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8E40C@szxeml545-mbx.china.huawei.com> <50A59C1F.2040407@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8E520@szxeml545-mbx.china.huawei.com> <50A5BB8E.6010308@bogus.com> <50A60934.5090507@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B6307474087B8@mbx-01.win.nominum.com> <50A685D7.5030507@s-carlsen.dk> In-Reply-To: <50A685D7.5030507@s-carlsen.dk> 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: <01272ED24A41364DB4B225AB8AD735E4@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [dhcwg] [v6ops] some feedback on http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-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, 16 Nov 2012 18:51:30 -0000 On Nov 16, 2012, at 1:28 PM, Sten Carlsen wrote: > So given my level of understanding here I would like to ask where you see= this draft used? > 1 - Is it used by the ISP to control the SOHO hosts, I think that is not = a good solution. The ISP DHCP server never talks directly to SOHO hosts, so I don't see how = this solution could be implemented. Remember that the SOHO router is gett= ing a prefix delegation from the ISP; it is by definition responsible for m= anaging addresses on that /64. > 2 - Is it used by the SOHO to control his own hosts, that would be fine, = except if the ISP needs to know which hosts are allowed to access the inter= net. I've never heard of an ISP filtering access to a limited number of hosts on= a wire. I don't think that is practical, since it would break temporary = addresses. > 3 - Is it used on link "b" only to control the router at the edge of the = SOHO and keep track of the ISPs own network units? This is the only model that makes any sense to me. From stenc@s-carlsen.dk Fri Nov 16 11:29: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 CCE1321F8AC9 for ; Fri, 16 Nov 2012 11:29:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.439 X-Spam-Level: X-Spam-Status: No, score=-1.439 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_DK=1.009, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qokw+Vnz-sm9 for ; Fri, 16 Nov 2012 11:29:58 -0800 (PST) Received: from mail2.s-carlsen.dk (0134100024.0.fullrate.dk [90.185.128.210]) by ietfa.amsl.com (Postfix) with ESMTP id E778621F8A7A for ; Fri, 16 Nov 2012 11:29:57 -0800 (PST) Received: from silver4-wire.s-carlsen.dk (unknown [IPv6:2001:16d8:dd00:81ac:cabc:c8ff:fe91:1152]) by mail2.s-carlsen.dk (Postfix) with ESMTPA id 7067AFAD4; Fri, 16 Nov 2012 20:29:54 +0100 (CET) Message-ID: <50A69432.8030101@s-carlsen.dk> Date: Fri, 16 Nov 2012 20:29:54 +0100 From: Sten Carlsen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Ted Lemon References: <50A33EFA.7070008@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8E40C@szxeml545-mbx.china.huawei.com> <50A59C1F.2040407@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8E520@szxeml545-mbx.china.huawei.com> <50A5BB8E.6010308@bogus.com> <50A60934.5090507@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B6307474087B8@mbx-01.win.nominum.com> <50A685D7.5030507@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B630747408DF9@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630747408DF9@mbx-01.win.nominum.com> Content-Type: multipart/alternative; boundary="------------050002020509090900070906" Cc: "" Subject: Re: [dhcwg] [v6ops] some feedback on http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-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, 16 Nov 2012 19:29:58 -0000 This is a multi-part message in MIME format. --------------050002020509090900070906 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 16/11/12 19:51, Ted Lemon wrote: > On Nov 16, 2012, at 1:28 PM, Sten Carlsen > wrote: >> So given my level of understanding here I would like to ask where you see this draft used? >> 1 - Is it used by the ISP to control the SOHO hosts, I think that is not a good solution. > The ISP DHCP server never talks directly to SOHO hosts, so I don't see how this solution could be implemented. Remember that the SOHO router is getting a prefix delegation from the ISP; it is by definition responsible for managing addresses on that /64. Good, what I hoped for. With IPv4 it is sometimes a bit different - one might fear that habits follow to next technology. > >> 2 - Is it used by the SOHO to control his own hosts, that would be fine, except if the ISP needs to know which hosts are allowed to access the internet. > I've never heard of an ISP filtering access to a limited number of hosts on a wire. I don't think that is practical, since it would break temporary addresses. This does happen with IPv4, addresses are sparse and one might fear that the same habit could go to IPv6 - "You want three PCs talking to the internet, pay three slots". The answer I hoped for. > >> 3 - Is it used on link "b" only to control the router at the edge of the SOHO and keep track of the ISPs own network units? > This is the only model that makes any sense to me. I fully agree, this does make sense to me. Every link can use it to manage their own part of the chain but not more links. > Thanks for taking the time to answer my questions. -- Best regards Sten Carlsen No improvements come from shouting: "MALE BOVINE MANURE!!!" --------------050002020509090900070906 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit
On 16/11/12 19:51, Ted Lemon wrote:
On Nov 16, 2012, at 1:28 PM, Sten Carlsen <stenc@s-carlsen.dk>
 wrote:

So given my level of understanding here I would like to ask where you see this draft used?
1 - Is it used by the ISP to control the SOHO hosts, I think that is not a good solution.

The ISP DHCP server never talks directly to SOHO hosts, so I don't see how this solution could be implemented.   Remember that the SOHO router is getting a prefix delegation from the ISP; it is by definition responsible for managing addresses on that /64.
Good, what I hoped for. With IPv4 it is sometimes a bit different - one might fear that habits follow to next technology.


2 - Is it used by the SOHO to control his own hosts, that would be fine, except if the ISP needs to know which hosts are allowed to access the internet.

I've never heard of an ISP filtering access to a limited number of hosts on a wire.   I don't think that is practical, since it would break temporary addresses.
This does happen with IPv4, addresses are sparse and one might fear that the same habit could go to IPv6 - "You want three PCs talking to the internet, pay three slots".
The answer I hoped for.


3 - Is it used on link "b" only to control the router at the edge of the SOHO and keep track of the ISPs own network units?

This is the only model that makes any sense to me.
I fully agree, this does make sense to me. Every link can use it to manage their own part of the chain but not more links.
Thanks for taking the time to answer my questions.
-- 
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!"
--------------050002020509090900070906-- From budmillwood@gmail.com Fri Nov 16 14:42: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 8DC3A21F8461 for ; Fri, 16 Nov 2012 14:42:06 -0800 (PST) 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 mduLGhMBmP9K for ; Fri, 16 Nov 2012 14:42:05 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id C54EE21F845E for ; Fri, 16 Nov 2012 14:42:05 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id j26so2250535iaf.31 for ; Fri, 16 Nov 2012 14:42:05 -0800 (PST) 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=Grx0NDb6hmv9TnT6mypLqDNMjlBRFB5DxueZTwdJeWc=; b=gRxKCcYq6BzWJjJkM0p2eL7281aPuGRdpxiDLQrZ03QAoXlr+8nv3c5b42LKSHhygw oTYWdq43Rz7hr2hWVcb4nKW/62xNv0NvSY+IuD0tO04bGalXTH2KF3VjtRfFpnajDOOr w6PSyNeLrBlDGXt9imLEcbL3CjMCxUsZa/FrQZKfJAbQzEl/wqkOhseaRh3KquzifKEt UV+kFC3e0/PY8N7f9PBf+R9t521XYFEUwEjTZ+lZ7O+zAUtlT45qo5qeK+TIdGqRqQ78 hvBKT2vWgKgmXBl7SykT6cNcAUb22dGynzbOk0qnyKmsno+cu47rIu3EWedi9yYkxZuc E7Cw== MIME-Version: 1.0 Received: by 10.42.41.142 with SMTP id p14mr4804406ice.36.1353105725237; Fri, 16 Nov 2012 14:42:05 -0800 (PST) Received: by 10.64.8.236 with HTTP; Fri, 16 Nov 2012 14:42:05 -0800 (PST) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E95C9F87B@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E947B0E73@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E95C9F87B@PUEXCB1B.nanterre.francetelecom.fr> Date: Fri, 16 Nov 2012 23:42:05 +0100 Message-ID: From: Bud Millwood To: mohamed.boucadair@orange.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "" Subject: Re: [dhcwg] IP address vs. FQDN discussion X-BeenThere: dhcwg@ietf.org 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, 16 Nov 2012 22:42:06 -0000 If I understand this correctly, it's a proposal to allow sending either a name or ip address encoded as a string? Space in DHCPv4 packets is limited. Encoding an IP address as text is a huge waste of valuable packet space for that protocol. Also, proposing that multiple names be separated with whitespace is equivalent to either a) introducing a new encoding for sequences or b) having the option value treated as opaque date. If it's the latter, we lose the ability to verify that the payload is properly formatted. Some options use a type specifier, 0 or 1, to denote ip address or dns name. Is there any reason to not use that? - Bud On Thu, Nov 15, 2012 at 4:04 PM, wrote: > Dear Erik, > > Thanks for reading the draft and also for supporting this proposal. > > For information, I have submitted an updated version of the draft which i= s available at: > > http://tools.ietf.org/html/draft-boucadair-dhc-address-name-encoding-02 > > Comments from WG are more than welcome. > > Cheers, > Med > >>-----Message d'origine----- >>De : Erik Kline [mailto:ek@google.com] >>Envoy=E9 : jeudi 15 novembre 2012 04:24 >>=C0 : BOUCADAIR Mohamed OLNC/OLN >>Cc : >>Objet : Re: [dhcwg] IP address vs. FQDN discussion >> >>After a very cursory reading, I would say largely +1. I'm in favour >>of something like "a UTF-8 string intended to passed to a higher layer >>address resolution mechanism, a la getaddrinfo(), et cetera". >> >>On 8 November 2012 07:30, wrote: >>> Dear all, >>> >>> As this question is repeatedly raised, including in the >>ongoing dhc meeting, >>> we have edited a draft which proposes an approach which >>conciliates both >>> modes: It defines a name option encoded as UTF-8 string >>which can be a >>> domain name, IPv4 address literals, etc. The draft is available at: >>> >>> >>http://tools.ietf.org/html/draft-boucadair-dhc-address-name-encoding-01 >>> >>> Comments are welcome. >>> >>> Cheers, >>> Med >>> >>> >>> _______________________________________________ >>> 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 tjc@ecs.soton.ac.uk Sat Nov 17 04:19: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 7EB3F21F8765; Sat, 17 Nov 2012 04:19:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[AWL=0.245, 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 CN-3RTB2UBT3; Sat, 17 Nov 2012 04:19:34 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 5161E21F8206; Sat, 17 Nov 2012 04:19:34 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id qAHCJSkg010501; Sat, 17 Nov 2012 12:19:30 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk qAHCJSkg010501 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1353154770; bh=AWseN6Y2Uw8r40TUiuVKxt3HbbI=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=t6LbBvtCvVgg+/rMQeiKEmj+jsLgaN3kZMlRt0NoMp8hHgesidteMS69GG3OqSu+n LvNTYTY1kuhvv+DqNXqMdeZrzumOiBBiXU64bJPsrHUu98WbV1uLcxtX/UDV7MSH0Y AestAkookjTcUx3mhxUTZoy3o8sV9pJtuxqT8vRM= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id oAGCJS04306320666p ret-id none; Sat, 17 Nov 2012 12:19:30 +0000 Received: from [192.168.1.102] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id qAHCI5Yc026344 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 17 Nov 2012 12:18:06 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tim Chown In-Reply-To: <1353109754.80634.YahooMailNeo@web32501.mail.mud.yahoo.com> Date: Sat, 17 Nov 2012 12:18:05 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <50A33EFA.7070008@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8E40C@szxeml545-mbx.china.huawei.com> <50A59C1F.2040407@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8E520@szxeml545-mbx.china.huawei.com> <50A5BB8E.6010308@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8E5CB@szxeml545-mbx.china.huawei.com> <1353047488.86944.YahooMailNeo@web32501.mail.mud.yahoo.com> <8D23D4052ABE7A4490E77B1A012B630747408741@mbx-01.win.nominum.com> <1353109754.80634.YahooMailNeo@web32501.mail.mud.yahoo.com> To: dhcwg@ietf.org, IPv6 Ops WG , draft-ietf-dhc-addr-registration@tools.ietf.org X-Mailer: Apple Mail (2.1499) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=oAGCJS043063206600; tid=oAGCJS04306320666p; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=3:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: qAHCJSkg010501 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [dhcwg] [v6ops] some feedback on http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-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, 17 Nov 2012 12:19:35 -0000 On 16 Nov 2012, at 23:49, Mark Smith wrote: > Hi, >=20 > I think there are advantages to keeping the mechanisms to collect = information > about hosts and their addresses independent of how those addresses are > assigned or derived.=20 I think this is a fair point. I also can't help but think that there is likely to be some overlap = between what this draft is trying to do, and what we might end up with = as a result of the homenet and/or mdnsext work in extending zeroconf = methods to home and enterprise/campus networks. Simply for address usage tracking, we've found it sufficient to run = tools that poll the switch/router infrastructure. We do that on a campus = using open source tools and it works just fine, provided the polling is = configured to take into account the expiration timers of the data being = gathered from the devices. Where the tool is also aware of the all the = network devices, their connectivity, prefix allocations, VLANs, switch = port configurations, etc, then you have pretty much all you need for = accountability. We also use 802.1X for wireless (eduroam) and are = beginning to use it for wired ports as well. I've not looked at Fernando's tool. I would assume it achieves the same = thing in terms of address tracking, but I'd argue that integrating the = polling/tracking with network monitoring/management tools that have the = 'bigger picture' is advantageous. Tim= From markzzzsmith@yahoo.com.au Thu Nov 15 22:31: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 479DC21F8856 for ; Thu, 15 Nov 2012 22:31:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=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 xrI+ehwS352Z for ; Thu, 15 Nov 2012 22:31:38 -0800 (PST) Received: from nm33-vm3.bullet.mail.ne1.yahoo.com (nm33-vm3.bullet.mail.ne1.yahoo.com [98.138.229.67]) by ietfa.amsl.com (Postfix) with ESMTP id D3E0D21F8855 for ; Thu, 15 Nov 2012 22:31:37 -0800 (PST) Received: from [98.138.90.49] by nm33.bullet.mail.ne1.yahoo.com with NNFMP; 16 Nov 2012 06:31:29 -0000 Received: from [98.138.89.163] by tm2.bullet.mail.ne1.yahoo.com with NNFMP; 16 Nov 2012 06:31:29 -0000 Received: from [127.0.0.1] by omp1019.mail.ne1.yahoo.com with NNFMP; 16 Nov 2012 06:31:29 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 702167.3607.bm@omp1019.mail.ne1.yahoo.com Received: (qmail 99848 invoked by uid 60001); 16 Nov 2012 06:31:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1353047489; bh=HkLkB9MNAaDTsYZnHcEP4T2DHT0uPInRhIGlJ7DUrkM=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=OvzMyDlt5W7GopBy+EN6BbOQpUgEQumUtiiedd8qj4OdQNFGQuOe10gDRKQdW/Kj1JevN5vLPwz8Gr5xpXKBeGHCQXm4OwJUeWooe37RnjnMJ/554/lPYmPc+mOMye2QsNFLqd1nmG0MfjVykesmZvMf4FN32xal/hFlUKlT8f0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Dpjyu0tWoAzlcnyWG9jRqqYAL4eYj7lwOOWRAq+fBNS7Mc8l+dpZRo2FsoRqemNO7eg3fhFp9vnu/k6kUFgsQtF0UuMxaXciNAgHjhGKclLpqTiKyxppbW2yRdJP0Cw0hbHewl/BmMJexdLr+BA9d6IYCLp9xtuxrCeGtFC/NgA=; X-YMail-OSG: JBiZBxMVM1mc5PInCGYsde.IJvMiixNrIuFPwEltS4CnVGP Gr5Ysp8Y0D3aQ1piUuvEK.EBkN3VdG11FNF2XXF5iGbYrQA7wogIQ8bm_98e 3OgRGiefRGj94alZ1RxrGKpFNAEYRuZjqCiueHtsnGnMhl4NPzZjkaBcN.FP 5nryDV5ODu6_tbcVxJqSZjo4p9AtvqVpZLoUo6zcYXiwDYahdDy9W_dkQKIA kEoFTEm3aVsiK81mbMPHOux5PATDmwyjAwWEmApO3D464sDe3MOFtcxN_hR4 BPQufth7G3c_rbD3TVKUtQl1GoxcSPZgSYIf2syxZFAtB2EWOPkXbSFDNjIy D5.bHROi0kzOQZ3uzVl_aVSw8AbETLY3evPXEz9.IBl75Dj2BWEKk3Z9KAuF 52hMO_z0pPYSl1YWXvNxy6wG1dd84spzv8mjLpDRsE1UvLaAdJJyHMqJK_or JiSdeKb0qDHa7LB1aBCNIT_MqSCaTawtILdycEPyA.dlnDlsGvxWWUePXnUf HuY.jRA054yXThfdjOipQOlbsGUBQB45xbISxYzwiOvwakhyCdDVg55s_Rpr EH4UNeEnOuPitctkASXK3vrYTWWlYGjfqc7tnvSVg_ShoEQ-- Received: from [121.200.231.211] by web32501.mail.mud.yahoo.com via HTTP; Thu, 15 Nov 2012 22:31:28 PST X-Rocket-MIMEInfo: 001.001, SSBhZ3JlZSB3aXRoIEpvZWwsIEkgdGhpbmsgb2JzZXJ2YXRpb24gYnkgbW9zdCBsaWtlbHkgYSByb3V0ZXIgaXMgYSBiZXR0ZXIgbWV0aG9kLCBhcyBpdCB3aWxsIGNhcHR1cmUgYWRkcmVzcyBpbmZvcm1hdGlvbiByZWdhcmRsZXNzIG9mIHdoZXRoZXIgaXQgd2FzIGNvbmZpZ3VyZWQgdmlhIHN0YXRpYywgU0xBQUMgb3IgREhDUHY2IChvciBhbnkgZnV0dXJlIG1ldGhvZHMpLgoKSSBoYXZlbid0IGhhZCBhIGNoYW5jZSB0byBydW4gRmVybmFuZG8ncyB1dGlsaXR5LCBob3dldmVyIEkgdW5kZXJzdGFuZCBpdCABMAEBAQE- X-Mailer: YahooMailWebService/0.8.123.460 References: <50A33EFA.7070008@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8E40C@szxeml545-mbx.china.huawei.com> <50A59C1F.2040407@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8E520@szxeml545-mbx.china.huawei.com> <50A5BB8E.6010308@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8E5CB@szxeml545-mbx.china.huawei.com> Message-ID: <1353047488.86944.YahooMailNeo@web32501.mail.mud.yahoo.com> Date: Thu, 15 Nov 2012 22:31:28 -0800 (PST) From: Mark Smith To: Sheng Jiang , joel jaeggli In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B9239F8E5CB@szxeml545-mbx.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sun, 18 Nov 2012 08:11:49 -0800 Cc: "dhcwg@ietf.org" , IPv6 Ops WG , "draft-ietf-dhc-addr-registration@tools.ietf.org" Subject: Re: [dhcwg] [v6ops] some feedback on http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 06:31:38 -0000 I agree with Joel, I think observation by most likely a router is a better = method, as it will capture address information regardless of whether it was= configured via static, SLAAC or DHCPv6 (or any future methods).=0A=0AI hav= en't had a chance to run Fernando's utility, however I understand it implem= ents address recording using observation.=0A=0Ahttp://www.si6networks.com/t= ools/ipv6mon/=0A=0A=0A=0A----- Original Message -----=0A> From: Sheng Jiang= =0A> To: joel jaeggli =0A> Cc: "d= hcwg@ietf.org" ; IPv6 Ops WG ; "draft-ietf-= dhc-addr-registration@tools.ietf.org" =0A> Sent: Friday, 16 November 2012 5:11 PM=0A> Subject: Re: [v= 6ops] some feedback on http://tools.ietf.org/html/draft-ietf-dhc-addr-regis= tration-01=0A> =0A>>>>> In reality, malicious hosts do not follow the RFCs.= =0A>>>> untrustworthy hosts aren't necessarily malicious.=0A>>> Ok. Let's= discuss which part you don't trust from hosts. There =0A> are several=0A>>= > possibilities I can think out: a) hosts refuse to register their =0A> add= resses, b) hosts=0A>>> register wrong address/mac on purpose=0A> =0A>> What= is wrong MAC in this case? =0A> =0A> I referred to these malicious hosts, = who uses faked MAC to get network access or =0A> plays to be other hosts.= =0A> =0A>> MACs are generally but not always stable=0A>> (vrrp6 is a pretty= good case for not stable), in any event they are=0A>> reconfigurable. A MA= C is a layer 2 binding and if you have a strong=0A>> layer-2 authentication= (as some centrally managed networks do) then=0A>> forgery is essentially i= rrelvant. beyond that the correctness of a MAC=0A>> absent ACLs, is limited= to it's presence in the bridge table and any=0A>> l2/l3 bindings it may ha= ve.=0A> =0A> Then, why hosts are untrustworthy to register address?=0A> =0A= >>>> I can with relatively minor effort on the part of a vendor capture = =0A> the=0A>>>> same information, with a lot less signaling out of the NDP= cache on =0A> my=0A>>>> routers, and do so without consideration of hosts= behavior.=0A>>> I agree with you if we only discuss the scenario that fir= st-hop router =0A> is fully=0A>>> under management by ISPs. But there are o= ther scenarios, in which =0A> first-hop=0A>>> router is home gateway, mobil= e node and others. For these scenarios, ISP=0A>>> cannot get the address in= formation unless host registering.=0A> =0A>> Either the network is centrall= y managed or it isn't. The draft describes=0A>> a management entity (enterp= rise) which is fully in control of the first=0A>> hop router(s). Here you'r= e describing a transitory trust model where my=0A>> first hop router manage= d by me passes a registration option to my hosts=0A>> to register addresses= used on my network with my ISP. That's not, in=0A>> your document.=0A> =0A= > Yes, it was not in the document. Since this document is a DHC draft, we f= ocused =0A> on the DHCP Protocol interaction and option definition. We did = not do very well =0A> to describe suitable scenarios until recently. We wil= l work on that. Thanks to =0A> help us improve the document.=0A> =0A>> The = network in my house, or my enterprise is managed by me, my ISP once=0A>> th= ey've assigned or delegated a prefix doesn't get to determine if I =0A> can= =0A>> use an address or not. It is no business of my ISP, if my fridge, or= =0A>> thermostat decides to use SLAAC to assign an address from the prefix= =0A>> which it plans to use becuase it's covered by RA.=0A>> =0A>>> Anothe= r point is this new registration is bi-direction interaction. It =0A> gives= ISPs=0A>>> a chance to manage these host-generated addresses, such as deny= ing =0A> certain=0A>>> address (such as low sec-value CGA), etc. For now, I= SPs has to accept =0A> all=0A>>> host-generated addresses. If ISP denies ac= cess because of any=0A>>> address-relevant reasons, there is no mechanism t= o tell hosts why and =0A> how to=0A>>> fix it.=0A> =0A>> Interesting use ca= se. It's not in the document however, which you do=0A>> have is.=0A>> =0A>>= =A0 =A0 After receiving this address registration request, the address=0A>= > =A0 =A0 registration server MUST register the requested address in its=0A= >> =A0 =A0 address database, which may further be used by other network=0A>= > =A0 =A0 functions, such as DNS, network access control lists, etc.=0A>> = =0A>> so presumably you tell the IA that it can't have an address by settin= g=0A>> preferred-lifetime and valid-lifetime fields to 0, that doens't seem= =0A> like an=0A>> extremely useful message to send back out a client tryin= g to register an=0A>> address.=0A> =0A> Agree, more information should be p= rovided in the case of reject address. =0A> Actually, the specific case of = denying CGA with low sec-value was solved by =0A> another dedicated draft = =0A> (http://tools.ietf.org/html/draft-ietf-dhc-cga-config-dhcpv6) , in whi= ch a new =0A> DHCPv6 option has been defined to feedback a recommended Sec = value.=0A> =0A> We will improve this part in next update.=0A> =0A> Best reg= ards,=0A> =0A> Sheng=0A> =0A>> Fundamentally if you don't control the netwo= rk you shouldn't be =0A> managing=0A>> address selection on it since you do= n't know what people will attach. if=0A>> you do then by all means do so.= =0A>> =0A>> =0A>>> Best regards,=0A>>> =0A>>> Sheng=0A>>> =0A>>>>> Best = regards,=0A>>>>> =0A>>>>> Sheng=0A>>>>> =0A>>>>>> If a strong assertion o= f L2 identity in support of l2/l3 =0A> bindings is=0A>>>>>> required 802.1= x or the wireless equivalanet seems =0A> appropiate, e.g. it's=0A>>>>>> wh= at we do today.=0A>>>>>> =0A>>>>>> Availing oneself of a dhcp/ra option en= tails a lot of =0A> signaling for what=0A>>>>>> is likely a relatively eph= emeral port (windows machines and =0A> macs=0A>>>>>> registering privacy a= ddresses for example). specifiying a =0A> binding=0A>>>>>> lifetime seems = of limited utility since the host will =0A> probably discard=0A>>>>>> the = address long before the lifetime expires if it's =0A> sufficently long=0A>>= >>>> enough to allow for long lived connections using that =0A> address.= =0A>>>>>> _______________________________________________=0A>>>>>> v6ops = mailing list=0A>>>>>> v6ops@ietf.org=0A>>>>>> https://www.ietf.org/mailma= n/listinfo/v6ops=0A>>> =0A> =0A> __________________________________________= _____=0A> v6ops mailing list=0A> v6ops@ietf.org=0A> https://www.ietf.org/ma= ilman/listinfo/v6ops=0A> From markzzzsmith@yahoo.com.au Fri Nov 16 15:49: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 657B121F8B25 for ; Fri, 16 Nov 2012 15:49:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.258 X-Spam-Level: X-Spam-Status: No, score=-1.258 tagged_above=-999 required=5 tests=[AWL=0.841, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] 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 zBwqyuQGipqw for ; Fri, 16 Nov 2012 15:49:22 -0800 (PST) Received: from nm13-vm2.bullet.mail.ne1.yahoo.com (nm13-vm2.bullet.mail.ne1.yahoo.com [98.138.91.89]) by ietfa.amsl.com (Postfix) with ESMTP id 0099221F8B23 for ; Fri, 16 Nov 2012 15:49:21 -0800 (PST) Received: from [98.138.226.180] by nm13.bullet.mail.ne1.yahoo.com with NNFMP; 16 Nov 2012 23:49:14 -0000 Received: from [98.138.87.1] by tm15.bullet.mail.ne1.yahoo.com with NNFMP; 16 Nov 2012 23:49:14 -0000 Received: from [127.0.0.1] by omp1001.mail.ne1.yahoo.com with NNFMP; 16 Nov 2012 23:49:14 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 874013.82882.bm@omp1001.mail.ne1.yahoo.com Received: (qmail 96796 invoked by uid 60001); 16 Nov 2012 23:49:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1353109754; bh=qZuG2Il6poJVkp1h78Cou8s8va6f5K4j9d6B7bWaL7s=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=x2AbUiggxG3mchadIMDuo/tuyvD2iHJdO4LttCetGF0qy3XInDsujqHYkrOiYRtmDCXM8MS2C7w9kv0hI2IPQ8QsEDtTbVcVabLGUzl7xd5vV4IvzTuPt21heVjkrkWz0Gs84pS/lbPUlsjX6Nqn69S8tSZfwXp464MJddNOlMY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=jJIhcYoL0/13l05gJQNrcyfhgjYhJc5zbpOV/PUTIKokLkcchv+SU2St66DhxEV3PDgg83aSZXNJ9/w003t0CA0zY3v7ToW6Lu5xZe6s28daMuaNVHaMrJrmvNIfuhuUp/QUYJuSQcdmV3pfWzmEmXuxjYUcbniEC1Vgsq8/U3U=; X-YMail-OSG: Eaqq5egVM1llOtuiR5OIDPfgPU_OaoK0XBsvxwnQMvm2lLJ 7ZOankvcrPdTo0FlX4836Mpp_Yoj0qA50fsP5q6SZRvPrU3k_si35MaUVmOZ DB5Jt5wTPpR3OVH6Juy_PdYhKrtbwrSDCsnrmgZ9zdX3LgmrYad2w1Wf8ZbD VhtPG9BQ3iNKEpWNhB6rHYWH_tN7eaSJqjx5oX02.ihP80yN4UiJROzQPX6A oW_Zs0L0EXfM4RaA3LyuLYtgi9yNxead.5SX6FycuTVxMuBUpZ3BEU44kmD3 q07ER261HFPdQj5vQgrZr6JoSXcniOE6cHmzXTee71kG0EsJ31FpvbwGEFBE ucCCEHxLPc0dHCXMxy5dfQ9YnJApHrW2d7iRjj4zhcQ99O49O9GGohe5KUBk T6jfGutYMTiS4mu9cOiomY0kik4jrq8yyPx_1Zjm2dat9WkspmJ8KoqlOitZ q81DeI3.sjWcOHSPuJpq7p1jRmdlbGZrGQ7_2DkDdVqpQT_lDlqs576raee9 invmz16WaQ1KRaizE Received: from [150.101.221.237] by web32501.mail.mud.yahoo.com via HTTP; Fri, 16 Nov 2012 15:49:14 PST X-Rocket-MIMEInfo: 001.001, SGksCgoKLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQo.IEZyb206IFRlZCBMZW1vbiA8VGVkLkxlbW9uQG5vbWludW0uY29tPgo.IFRvOiBNYXJrIFNtaXRoIDxtYXJrenp6c21pdGhAeWFob28uY29tLmF1Pgo.IENjOiBTaGVuZyBKaWFuZyA8amlhbmdzaGVuZ0BodWF3ZWkuY29tPjsgam9lbCBqYWVnZ2xpIDxqb2VsamFAYm9ndXMuY29tPjsgImRoY3dnQGlldGYub3JnIiA8ZGhjd2dAaWV0Zi5vcmc.OyBJUHY2IE9wcyBXRyA8djZvcHNAaWV0Zi5vcmc.OyAiZHJhZnQtaWV0Zi1kaGMtYWRkci1yZWdpc3QBMAEBAQE- X-Mailer: YahooMailWebService/0.8.123.460 References: <50A33EFA.7070008@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8E40C@szxeml545-mbx.china.huawei.com> <50A59C1F.2040407@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8E520@szxeml545-mbx.china.huawei.com> <50A5BB8E.6010308@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8E5CB@szxeml545-mbx.china.huawei.com> <1353047488.86944.YahooMailNeo@web32501.mail.mud.yahoo.com> <8D23D4052ABE7A4490E77B1A012B630747408741@mbx-01.win.nominum.com> Message-ID: <1353109754.80634.YahooMailNeo@web32501.mail.mud.yahoo.com> Date: Fri, 16 Nov 2012 15:49:14 -0800 (PST) From: Mark Smith To: Ted Lemon In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630747408741@mbx-01.win.nominum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sun, 18 Nov 2012 08:11:49 -0800 Cc: joel jaeggli , "dhcwg@ietf.org" , IPv6 Ops WG , "draft-ietf-dhc-addr-registration@tools.ietf.org" Subject: Re: [dhcwg] [v6ops] some feedback on http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 23:49:22 -0000 Hi,=0A=0A=0A----- Original Message -----=0A> From: Ted Lemon =0A> To: Mark Smith =0A> Cc: Sheng Jian= g ; joel jaeggli ; "dhcwg@ietf.org= " ; IPv6 Ops WG ; "draft-ietf-dhc-addr-regi= stration@tools.ietf.org" = =0A> Sent: Saturday, 17 November 2012 12:40 AM=0A> Subject: Re: [v6ops] som= e feedback on http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-0= 1=0A> =0A> On Nov 16, 2012, at 1:31 AM, Mark Smith wrote:=0A>> I agree with Joel, I think observation by most likely a ro= uter is a better =0A> method, as it will capture address information regard= less of whether it was =0A> configured via static, SLAAC or DHCPv6 (or any = future methods).=0A> =0A> It's certainly true that a router can capture all= the IPv4 and IPv6 =0A> addresses that a device with a particular MAC addre= ss uses.=A0 However, what a =0A> router _can't_ do, and what this option a= llows to be done, is for a device =0A> that has autoconfigured to then prov= ide the network administrator with a hint as =0A> to what its FQDN should b= e.=A0 This information isn't available to the =0A> router.=0A> =0A> It see= ms to me that although it is true that it is worthwhile to define a =0A> me= chanism for getting common address information from a router, this is =0A> = orthogonal to the question of whether a client-based mechanism for address = =0A> registration is useful.=A0 It seems to me that there are three broad = =0A> classifications of use cases here:=0A> =0A> 1. In an environment where= address registration is mandatory, and hosts are =0A> tightly controlled, = this protocol may suffice.=0A> 2. In an environment where address registrat= ion is optional/advisory, this=A0=0A=0A> protocol may suffice, since presum= ably the reason you register addresses is to =0A> track client-sourced info= rmation like hostname that relates to the address.=0A> 3. In an environment= where address registration is mandatory and hosts are not =0A> tightly con= trolled, you need support for address registration on the router.=A0 =0A> H= owever, you can _still_ benefit in this case from the DHCP-based address = =0A> registration protocol; devices that support it can still provide hints= about the =0A> FQDN they want.=0A> =0A> I point this out because the reaso= n I support this draft is the FQDN use case.=A0 =0A> This is a use case tha= t has seen substantial use in enterprise environments in =0A> IPv4.=A0 We = do not currently have a solution to the problem for IPv6, because in =0A> I= Pv6 we don't require DHCP for host configuration.=A0 This DHCP extension = =0A> allows us to leverage a DHCP infrastructure without _requiring_ that h= osts =0A> autoconfigure using DHCP, and without even _requiring_ that hosts= register their =0A> addresses at all.=0A> =0A> I think Sheng has a differe= nt use case in mind, and from what I can tell his use =0A> case falls into = the first category, where mine falls into the second.=A0 I know =0A> of ot= her enterprise users who have use cases that fall into category 3; for =0A>= them, this protocol will not be sufficient, and they will need the router-= based =0A> protocol either instead, or as well.=0A> =0A=0AIt seems to me th= at either RFC3122 - "Extensions to IPv6 Neighbor Discovery=0A=0Afor Inverse= Discovery Specification" and/or RFC4620 - "IPv6 Node Information=0AQueries= " might be able to meet those needs. Where they considered?=0A=0AI think th= ere are advantages to keeping the mechanisms to collect information=0Aabout= hosts and their addresses independent of how those addresses are=0Aassigne= d or derived. For example, it seems that it might be valid to have=0Aa host= use both SLAAC (i.e. PIO with the A bit on) and DHCPv6 (RA with the=0AM bi= t on) to configure it's addresses, as the M bit doesn't say that A bits=0Ai= n PIOs must be ignored or vice versa. While a link will usually use one or = the other=0Aof the methods, the use case is a period of transition between = the two=0Ae.g. moving from SLAAC to DHCPv6. There is some evidence that Win= dows 7=0Ahas adopted the exclusive one or the other approach to SLAAC and D= HCPv6,=0Aand that is causing an issue when there is a later RA that has a d= ifferent M=0Abit value i.e. the later RA has the M bit switched off, to mov= e the subnet=0Afrom DHCPv6 address assignment to SLAAC based assignment, an= d the DHCPv6=0Aaddresses are being expired immediately, regardless of the p= referred and=0Avalid lifetimes that the DHCPv6 server announced. In other w= ords, instead=0Aof being able to do a phased and gradual transition from DH= CPv6 to SLAAC=0Avia preferred and valid lifetimes, this is forcing a disrup= tive change.=0A=0AStatic addresses, and Tokenised IPv6 identifiers=0A(http:= //tools.ietf.org/html/draft-chown-6man-tokenised-ipv6-identifiers-02)=0Awou= ld also be a reason to try to use address and host information query=0Ameth= ods that are address configuration method independent.=0A=0ARegards,=0AMark= . From jiangsheng@huawei.com Sun Nov 18 18:10: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 251BE21F84CF; Sun, 18 Nov 2012 18:10:37 -0800 (PST) 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 ZiCYjp0KHRRq; Sun, 18 Nov 2012 18:10:33 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4317F21F84CC; Sun, 18 Nov 2012 18:10:31 -0800 (PST) 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 AMX51124; Mon, 19 Nov 2012 02:10:29 +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, 19 Nov 2012 02:10:05 +0000 Received: from SZXEML460-HUB.china.huawei.com (10.82.67.203) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 19 Nov 2012 02:10:27 +0000 Received: from szxeml545-mbx.china.huawei.com ([169.254.1.6]) by szxeml460-hub.china.huawei.com ([10.82.67.203]) with mapi id 14.01.0323.003; Mon, 19 Nov 2012 10:10:24 +0800 From: Sheng Jiang To: Maglione Roberta , "'Leaf Yeh'" Thread-Topic: [Softwires] Last Call: (RADIUS Attribute for 6rd) to Proposed Standard Thread-Index: AQHNxAP5LyU1QcTX80yMPtxTT00nhZfwafBg Date: Mon, 19 Nov 2012 02:10:23 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B9239F8ECAC@szxeml545-mbx.china.huawei.com> References: <20121115213918.3949.85119.idtracker@ietfa.amsl.com> <50a63503.848f440a.6460.6ac1@mx.google.com> <282BBE8A501E1F4DA9C775F964BB21FE519AC44BEA@GRFMBX704BA020.griffon.local> <50a6465d.4b53440a.7e28.73cc@mx.google.com> <282BBE8A501E1F4DA9C775F964BB21FE519AC44BEB@GRFMBX704BA020.griffon.local> In-Reply-To: <282BBE8A501E1F4DA9C775F964BB21FE519AC44BEB@GRFMBX704BA020.griffon.local> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.140] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "softwires@ietf.org" , "dhcwg@ietf.org" , "ietf@ietf.org" Subject: Re: [dhcwg] [Softwires] Last Call: (RADIUS Attribute for 6rd) to Proposed Standard X-BeenThere: dhcwg@ietf.org 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, 19 Nov 2012 02:10:37 -0000 SGksIFJvYmVydGEgYW5kIExlYWYsDQoNCkNhcmVmdWxseSBjaGVja2VkIFJGQzIxMzEsIHRoZSBv cmlnaW5hbCB0ZXh0IHdhcyByaWdodCwgYnV0IG5vdCBjbGVhcmx5IGRlZmluZSB0aGUgdGltZSB0 aGF0IGNsaWVudCBlbnRlcnMgUkVCSU5ESU5HIHN0YXRlLiBTbyBMZWFmJ3MgY29tbWVudHMgYWxz byByaWdodC4gTmV3IHRleHQgd2lsbCBiZSB0aGUgYmVsb3cuIEl0IHdvdWxkIGJlIGFkZGVkIGFm dGVyIEFEJ3MgaW5zdHJ1Y3Rpb24gZm9yIG5leHQgdXBkYXRlLCBtYXliZSB3aXRoIG90aGVyIGNv bW1lbnRzIGZyb20gSUVTRy4gDQoNCklmIHRoZSBESENQIHNlcnZlciB0byB3aGljaCB0aGUgREhD UCBSZXF1ZXN0IG1lc3NhZ2Ugd2FzIHNlbnQgYXQgdGltZSANCiAgIFQxIGhhcyBub3QgcmVzcG9u ZGVkICJ0aWxsIFQyIiwgdGhlIERIQ1AgY2xpZW50IGVudGVycyB0aGUgUkVCSU5ESU5HIHN0YXRl IGFuZCANCiAgIGF0dGVtcHRzIHRvIGNvbnRhY3QgYW55IHNlcnZlci4NCg0KTWFueSB0aGFua3Mg YW5kIGJlc3QgcmVnYXJkcywNCg0KU2hlbmcNCg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+RnJvbTogTWFnbGlvbmUgUm9iZXJ0YSBbbWFpbHRvOnJvYmVydGEubWFnbGlvbmVAdGVsZWNv bWl0YWxpYS5pdF0NCj5TZW50OiBGcmlkYXksIE5vdmVtYmVyIDE2LCAyMDEyIDEwOjA5IFBNDQo+ VG86ICdMZWFmIFllaCc7IFNoZW5nIEppYW5nDQo+Q2M6IHNvZnR3aXJlc0BpZXRmLm9yZzsgZGhj d2dAaWV0Zi5vcmc7IGlldGZAaWV0Zi5vcmcNCj5TdWJqZWN0OiBSRTogW1NvZnR3aXJlc10gTGFz dCBDYWxsOiA8ZHJhZnQtaWV0Zi1zb2Z0d2lyZS02cmQtcmFkaXVzLWF0dHJpYi0wNy50eHQ+DQo+ KFJBRElVUyBBdHRyaWJ1dGUgZm9yIDZyZCkgdG8gUHJvcG9zZWQgU3RhbmRhcmQNCj4NCj5MZWFm LA0KPkluIG15IG9waW5pb24gY3VycmVudCB0ZXh0IGlzIGZpbmUgYW5kIGlubGluZSB3aXRoIFJG QzIxMzEsIHdoaWxlIHRoZSB0ZXh0IHlvdQ0KPmFyZSBwcm9wb3NpbmcgaXMgbm90IGNvbXBsZXRl bHkgYWNjdXJhdGUgYmVjYXVzZSBpdCBkb2VzIG5vdCBjbGFyaWZ5ICJ3aGljaA0KPkRIQ1AgU2Vy dmVyIiBoYXMgbm90IHJlcGxpZWQuDQo+DQo+J0lmIHRoZSBESENQIHNlcnZlciBoYXMgbm90IHJl cGxpZWQgdGhlDQo+REhDUFJFUVVFU1QgbWVzc2FnZSB0aWxsIFQyLCB0aGUgREhDUCBjbGllbnQg ZW50ZXJzIGludG8gdGhlIFJFQklORElORw0KPnN0YXRlDQo+YW5kIGF0dGVtcHRzIHRvIGNvbnRh Y3QgYW55IHBvc3NpYmxlIHNlcnZlci4gJw0KPg0KPlNoZW5nLA0KPiBBcyBvcmlnaW5hbCBhdXRo b3Igb2YgdGhpcyB0ZXh0LCB3aGF0IGRvIHlvdSB0aGluaz8NCj4NCj5UaGFua3MsDQo+Um9iZXJ0 YQ0KPg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogTGVhZiBZZWggW21haWx0 bzpsZWFmLnllaC5zZG9AZ21haWwuY29tXQ0KPlNlbnQ6IEZyaWRheSwgTm92ZW1iZXIgMTYsIDIw MTIgMjo1OCBQTQ0KPlRvOiBNYWdsaW9uZSBSb2JlcnRhOyBpZXRmQGlldGYub3JnDQo+Q2M6IHNv ZnR3aXJlc0BpZXRmLm9yZzsgZGhjd2dAaWV0Zi5vcmcNCj5TdWJqZWN0OiBSRTogW1NvZnR3aXJl c10gTGFzdCBDYWxsOiA8ZHJhZnQtaWV0Zi1zb2Z0d2lyZS02cmQtcmFkaXVzLWF0dHJpYi0wNy50 eHQ+DQo+KFJBRElVUyBBdHRyaWJ1dGUgZm9yIDZyZCkgdG8gUHJvcG9zZWQgU3RhbmRhcmQNCj4N Cj48Um9iZXJ0YT4gQWNjb3JkaW5nIHRvIHNlY3Rpb24gNC40LjUgb2YgUkZDIDIxMzE6DQo+IiBB dCB0aW1lIFQxIHRoZSBjbGllbnQgbW92ZXMgdG8gUkVORVdJTkcgc3RhdGUgYW5kIHNlbmRzICh2 aWEgdW5pY2FzdCkNCj4gICBhIERIQ1BSRVFVRVNUIG1lc3NhZ2UgdG8gdGhlIHNlcnZlciB0byBl eHRlbmQgaXRzIGxlYXNlLiINCj5bLi5dDQo+IiBJZiBubyBESENQQUNLIGFycml2ZXMgYmVmb3Jl IHRpbWUgVDIsIHRoZSBjbGllbnQgbW92ZXMgdG8gUkVCSU5ESU5HDQo+ICAgc3RhdGUgYW5kIHNl bmRzICh2aWEgYnJvYWRjYXN0KSBhIERIQ1BSRVFVRVNUIG1lc3NhZ2UgdG8gZXh0ZW5kIGl0cw0K PiAgIGxlYXNlLiINCj5UaGUgREhDUFJFUVVFU1QgaXMgc2VudCBhdCBUMSwgaW4gbXkgb3Bpbmlv biB0aGUgY3VycmVudCB0ZXh0IGlzIGNvcnJlY3QuDQo+PC9Sb2JlcnRhPg0KPg0KPg0KPkNvcnJl Y3QgYnV0IG5vdCBhY2N1cmF0ZS4gVGhlIGNsaWVudCBlbnRlcnMgdGhlIHJlYmluZGluZyBzdGF0 ZSBhZnRlciBUMg0KPmV4cGlyZWQuDQo+DQo+SG93IGFib3V0IHRvIHVwZGF0ZSB0aGUgdGV4dCB0 byBiZSAnSWYgdGhlIERIQ1Agc2VydmVyIGhhcyBub3QgcmVwbGllZCB0aGUNCj5ESENQUkVRVUVT VCBtZXNzYWdlIHRpbGwgVDIsIHRoZSBESENQIGNsaWVudCBlbnRlcnMgaW50byB0aGUgUkVCSU5E SU5HDQo+c3RhdGUNCj5hbmQgYXR0ZW1wdHMgdG8gY29udGFjdCBhbnkgcG9zc2libGUgc2VydmVy LiAnPw0KPg0KPg0KPkJlc3QgUmVnYXJkcywNCj5MZWFmDQo+DQo+DQo+DQo+LS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBNYWdsaW9uZSBSb2JlcnRhIFttYWlsdG86cm9iZXJ0YS5t YWdsaW9uZUB0ZWxlY29taXRhbGlhLml0XQ0KPlNlbnQ6IEZyaWRheSwgTm92ZW1iZXIgMTYsIDIw MTIgOToxMyBQTQ0KPlRvOiAnTGVhZiBZZWgnOyBpZXRmQGlldGYub3JnDQo+Q2M6IHNvZnR3aXJl c0BpZXRmLm9yZzsgPGRoY3dnQGlldGYub3JnPiBXRw0KPlN1YmplY3Q6IFJFOiBbU29mdHdpcmVz XSBMYXN0IENhbGw6DQo+PGRyYWZ0LWlldGYtc29mdHdpcmUtNnJkLXJhZGl1cy1hdHRyaWItMDcu dHh0PiAoUkFESVVTIEF0dHJpYnV0ZSBmb3IgNnJkKSB0bw0KPlByb3Bvc2VkIFN0YW5kYXJkDQo+ DQo+SGkgTGVhZiwNCj4+IFNlY3Rpb24gMyAtIElmIHRoZSBESENQIHNlcnZlciB0byB3aGljaCB0 aGUgREhDUCBSZXF1ZXN0IG1lc3NhZ2Ugd2FzIHNlbnQNCj4+IGF0IHRpbWUgIFQxIGhhcyBub3Qg cmVzcG9uZGVkLCB0aGUgREhDUCBjbGllbnQgZW50ZXJzIHRoZSBSRUJJTkRJTkcNCj5zdGF0ZQ0K Pj4gYW5kICBhdHRlbXB0cyB0byBjb250YWN0IGFueSBzZXJ2ZXIuDQo+DQo+PiBQZXIgdGhlIEZp Z3VyZSA1IGluIFJGQzIxMzEsIHRoZSBhYm92ZSAnVDEnIHNvdW5kcyAnVDInLg0KPihodHRwOi8v d3d3LnJmYy1lZGl0b3Iub3JnL3JmYy9yZmMyMTMxLnR4dCkNCj4NCj5XaHkgVDI/DQo+QWNjb3Jk aW5nIHRvIHNlY3Rpb24gNC40LjUgb2YgUkZDIDIxMzE6DQo+IiBBdCB0aW1lIFQxIHRoZSBjbGll bnQgbW92ZXMgdG8gUkVORVdJTkcgc3RhdGUgYW5kIHNlbmRzICh2aWEgdW5pY2FzdCkNCj4gICBh IERIQ1BSRVFVRVNUIG1lc3NhZ2UgdG8gdGhlIHNlcnZlciB0byBleHRlbmQgaXRzIGxlYXNlLiIN Cj5bLi5dDQo+DQo+IiBJZiBubyBESENQQUNLIGFycml2ZXMgYmVmb3JlIHRpbWUgVDIsIHRoZSBj bGllbnQgbW92ZXMgdG8gUkVCSU5ESU5HDQo+ICAgc3RhdGUgYW5kIHNlbmRzICh2aWEgYnJvYWRj YXN0KSBhIERIQ1BSRVFVRVNUIG1lc3NhZ2UgdG8gZXh0ZW5kIGl0cw0KPiAgIGxlYXNlLiINCj4N Cj5UaGUgREhDUFJFUVVFU1QgaXMgc2VudCBhdCBUMSwgaW4gbXkgb3BpbmlvbiB0aGUgY3VycmVu dCB0ZXh0IGlzIGNvcnJlY3QuDQo+VGhhbmtzDQo+UmVnYXJkcywNCj5Sb2JlcnRhDQo+DQo+LS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBzb2Z0d2lyZXMtYm91bmNlc0BpZXRmLm9y ZyBbbWFpbHRvOnNvZnR3aXJlcy1ib3VuY2VzQGlldGYub3JnXSBPbg0KPkJlaGFsZiBPZiBMZWFm IFllaA0KPlNlbnQ6IEZyaWRheSwgTm92ZW1iZXIgMTYsIDIwMTIgMTo0NCBQTQ0KPlRvOiBpZXRm QGlldGYub3JnDQo+Q2M6IHNvZnR3aXJlc0BpZXRmLm9yZw0KPlN1YmplY3Q6IFJlOiBbU29mdHdp cmVzXSBMYXN0IENhbGw6DQo+PGRyYWZ0LWlldGYtc29mdHdpcmUtNnJkLXJhZGl1cy1hdHRyaWIt MDcudHh0PiAoUkFESVVTIEF0dHJpYnV0ZSBmb3IgNnJkKSB0bw0KPlByb3Bvc2VkIFN0YW5kYXJk DQo+DQo+U2VjdGlvbiAzIC0gQWZ0ZXIgdGhlIEJORyByZXNwb25kcyB0byB0aGUgdXNlciB3aXRo DQo+ICAgYW4gQWR2ZXJ0aXNlIG1lc3NhZ2UsIHRoZSB1c2VyIHJlcXVlc3RzIGZvciBhIERIQ1Ag NnJkIE9wdGlvbiBieQ0KPiAgIGNhcnJ5aW5nIGEgUGFyYW1ldGVyIFJlcXVlc3Qgb3B0aW9uICg1 NSkgW1JGQzIxMzJdLg0KPg0KPlBlciB0aGUgRmlndXJlIDEgaW4gU2VjdGlvbiAzLCB0aGUgYWJv dmUgJ0FkdmVydGlzZSBtZXNzYWdlJyBzb3VuZHMgdGhlDQo+REhDUHY0IG1lc3NhZ2Ugb2YgJ0RI Q1BPRkZFUiAoMiknLg0KPihodHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL2Jvb3RwLWRo Y3AtcGFyYW1ldGVycy9ib290cC1kaGNwLXBhcmENCj5tZXRlcnMNCj4ueG1sKQ0KPg0KPg0KPlNl Y3Rpb24gMyAtIElmIHRoZSBESENQIHNlcnZlciB0byB3aGljaCB0aGUgREhDUCBSZXF1ZXN0IG1l c3NhZ2Ugd2FzIHNlbnQNCj5hdA0KPnRpbWUNCj4gICBUMSBoYXMgbm90IHJlc3BvbmRlZCwgdGhl IERIQ1AgY2xpZW50IGVudGVycyB0aGUgUkVCSU5ESU5HIHN0YXRlIGFuZA0KPiAgIGF0dGVtcHRz IHRvIGNvbnRhY3QgYW55IHNlcnZlci4NCj4NCj5QZXIgdGhlIEZpZ3VyZSA1IGluIFJGQzIxMzEs IHRoZSBhYm92ZSAnVDEnIHNvdW5kcyAnVDInLg0KPihodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3Jn L3JmYy9yZmMyMTMxLnR4dCkNCj4NCj4NCj5CZXN0IFJlZ2FyZHMsDQo+TGVhZg0KPg0KPg0KPg0K Pg0KPg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogc29mdHdpcmVzLWJvdW5j ZXNAaWV0Zi5vcmcgW21haWx0bzpzb2Z0d2lyZXMtYm91bmNlc0BpZXRmLm9yZ10gT24NCj5CZWhh bGYgT2YgVGhlIElFU0cNCj5TZW50OiBGcmlkYXksIE5vdmVtYmVyIDE2LCAyMDEyIDU6MzkgQU0N Cj5UbzogSUVURi1Bbm5vdW5jZQ0KPkNjOiBzb2Z0d2lyZXNAaWV0Zi5vcmcNCj5TdWJqZWN0OiBb U29mdHdpcmVzXSBMYXN0IENhbGw6DQo+PGRyYWZ0LWlldGYtc29mdHdpcmUtNnJkLXJhZGl1cy1h dHRyaWItMDcudHh0PiAoUkFESVVTIEF0dHJpYnV0ZSBmb3IgNnJkKSB0bw0KPlByb3Bvc2VkIFN0 YW5kYXJkDQo+DQo+DQo+VGhlIElFU0cgaGFzIHJlY2VpdmVkIGEgcmVxdWVzdCBmcm9tIHRoZSBT b2Z0d2lyZXMgV0cgKHNvZnR3aXJlKSB0byBjb25zaWRlcg0KPnRoZSBmb2xsb3dpbmcgZG9jdW1l bnQ6DQo+LSAnUkFESVVTIEF0dHJpYnV0ZSBmb3IgNnJkJw0KPiAgPGRyYWZ0LWlldGYtc29mdHdp cmUtNnJkLXJhZGl1cy1hdHRyaWItMDcudHh0PiBhcyBQcm9wb3NlZCBTdGFuZGFyZA0KPg0KPlRo ZSBJRVNHIHBsYW5zIHRvIG1ha2UgYSBkZWNpc2lvbiBpbiB0aGUgbmV4dCBmZXcgd2Vla3MsIGFu ZCBzb2xpY2l0cyBmaW5hbA0KPmNvbW1lbnRzIG9uIHRoaXMgYWN0aW9uLiBQbGVhc2Ugc2VuZCBz dWJzdGFudGl2ZSBjb21tZW50cyB0byB0aGUNCj5pZXRmQGlldGYub3JnIG1haWxpbmcgbGlzdHMg YnkgMjAxMi0xMS0yOS4gRXhjZXB0aW9uYWxseSwgY29tbWVudHMgbWF5IGJlDQo+c2VudCB0byBp ZXNnQGlldGYub3JnIGluc3RlYWQuIEluIGVpdGhlciBjYXNlLCBwbGVhc2UgcmV0YWluIHRoZSBi ZWdpbm5pbmcNCj5vZiB0aGUgU3ViamVjdCBsaW5lIHRvIGFsbG93IGF1dG9tYXRlZCBzb3J0aW5n Lg0KPg0KPkFic3RyYWN0DQo+DQo+DQo+ICAgSVB2NiBSYXBpZCBEZXBsb3ltZW50ICg2cmQpIGlz IG9uZSBvZiB0aGUgbW9zdCBwb3B1bGFyIG1ldGhvZHMgdG8NCj4gICBwcm92aWRlIGJvdGggSVB2 NCBhbmQgSVB2NiBjb25uZWN0aXZpdHkgc2VydmljZXMgc2ltdWx0YW5lb3VzbHkNCj4gICBkdXJp bmcgdGhlIElQdjQvSVB2NiBjby1leGlzdGluZyBwZXJpb2QuIFRoZSBEeW5hbWljIEhvc3QNCj4g ICBDb25maWd1cmF0aW9uIFByb3RvY29sIChESENQKSA2cmQgb3B0aW9uIGhhcyBiZWVuIGRlZmlu ZWQgdG8NCj4gICBjb25maWd1cmUgNnJkIEN1c3RvbWVyIEVkZ2UgKENFKS4gSG93ZXZlciwgaW4g bWFueSBuZXR3b3JrcywgdGhlDQo+ICAgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbiBtYXkgYmUg c3RvcmVkIGluIEF1dGhlbnRpY2F0aW9uDQo+ICAgQXV0aG9yaXphdGlvbiBhbmQgQWNjb3VudGlu ZyAoQUFBKSBzZXJ2ZXJzIHdoaWxlIHVzZXIgY29uZmlndXJhdGlvbg0KPiAgIGlzIG1haW5seSBm cm9tIEJyb2FkYmFuZCBOZXR3b3JrIEdhdGV3YXkgKEJORykgdGhyb3VnaCBESENQDQo+cHJvdG9j b2wuDQo+ICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgUmVtb3RlIEF1dGhlbnRpY2F0aW9uIERp YWwgSW4gVXNlciBTZXJ2aWNlDQo+ICAgKFJBRElVUykgYXR0cmlidXRlIHRoYXQgY2FycmllcyA2 cmQgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbiBmcm9tDQo+ICAgQUFBIHNlcnZlciB0byBCTkcu DQo+DQo+DQo+DQo+DQo+DQo+DQo+VGhlIGZpbGUgY2FuIGJlIG9idGFpbmVkIHZpYQ0KPmh0dHA6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1zb2Z0d2lyZS02cmQtcmFkaXVz LWF0dHJpYi8NCj4NCj5JRVNHIGRpc2N1c3Npb24gY2FuIGJlIHRyYWNrZWQgdmlhDQo+aHR0cDov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXNvZnR3aXJlLTZyZC1yYWRpdXMt YXR0cmliL2JhbGxvdA0KPi8NCj4NCj4NCj5ObyBJUFIgZGVjbGFyYXRpb25zIGhhdmUgYmVlbiBz dWJtaXR0ZWQgZGlyZWN0bHkgb24gdGhpcyBJLUQuDQo+DQo+DQo+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5Tb2Z0d2lyZXMgbWFpbGluZyBsaXN0DQo+ U29mdHdpcmVzQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zb2Z0d2lyZXMNCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPlNvZnR3aXJlcyBtYWlsaW5nIGxpc3QNCj5Tb2Z0d2lyZXNAaWV0Zi5vcmcNCj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NvZnR3aXJlcw0KPg0KPlF1ZXN0 byBtZXNzYWdnaW8gZSBpIHN1b2kgYWxsZWdhdGkgc29ubyBpbmRpcml6emF0aSBlc2NsdXNpdmFt ZW50ZSBhbGxlDQo+cGVyc29uZSBpbmRpY2F0ZS4gTGEgZGlmZnVzaW9uZSwgY29waWEgbyBxdWFs c2lhc2kgYWx0cmEgYXppb25lIGRlcml2YW50ZQ0KPmRhbGxhIGNvbm9zY2VuemEgZGkgcXVlc3Rl IGluZm9ybWF6aW9uaSBzb25vIHJpZ29yb3NhbWVudGUgdmlldGF0ZS4gUXVhbG9yYQ0KPmFiYmlh dGUgcmljZXZ1dG8gcXVlc3RvIGRvY3VtZW50byBwZXIgZXJyb3JlIHNpZXRlIGNvcnRlc2VtZW50 ZSBwcmVnYXRpIGRpDQo+ZGFybmUgaW1tZWRpYXRhIGNvbXVuaWNhemlvbmUgYWwgbWl0dGVudGUg ZSBkaSBwcm92dmVkZXJlIGFsbGEgc3VhDQo+ZGlzdHJ1emlvbmUsIEdyYXppZS4NCj4NCj5UaGlz IGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGlzIGNvbmZpZGVudGlhbCBhbmQgbWF5IGNvbnRh aW4gcHJpdmlsZWdlZA0KPmluZm9ybWF0aW9uIGludGVuZGVkIGZvciB0aGUgYWRkcmVzc2VlKHMp IG9ubHkuIERpc3NlbWluYXRpb24sIGNvcHlpbmcsDQo+cHJpbnRpbmcgb3IgdXNlIGJ5IGFueWJv ZHkgZWxzZSBpcyB1bmF1dGhvcmlzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZA0KPnJl Y2lwaWVudCwgcGxlYXNlIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2htZW50cyBh bmQgYWR2aXNlIHRoZQ0KPnNlbmRlciBieSByZXR1cm4gZS1tYWlsLCBUaGFua3MuDQo+DQo+DQo+ UXVlc3RvIG1lc3NhZ2dpbyBlIGkgc3VvaSBhbGxlZ2F0aSBzb25vIGluZGlyaXp6YXRpIGVzY2x1 c2l2YW1lbnRlIGFsbGUNCj5wZXJzb25lIGluZGljYXRlLiBMYSBkaWZmdXNpb25lLCBjb3BpYSBv IHF1YWxzaWFzaSBhbHRyYSBhemlvbmUgZGVyaXZhbnRlIGRhbGxhDQo+Y29ub3NjZW56YSBkaSBx dWVzdGUgaW5mb3JtYXppb25pIHNvbm8gcmlnb3Jvc2FtZW50ZSB2aWV0YXRlLiBRdWFsb3JhDQo+ YWJiaWF0ZSByaWNldnV0byBxdWVzdG8gZG9jdW1lbnRvIHBlciBlcnJvcmUgc2lldGUgY29ydGVz ZW1lbnRlIHByZWdhdGkgZGkNCj5kYXJuZSBpbW1lZGlhdGEgY29tdW5pY2F6aW9uZSBhbCBtaXR0 ZW50ZSBlIGRpIHByb3Z2ZWRlcmUgYWxsYSBzdWENCj5kaXN0cnV6aW9uZSwgR3JhemllLg0KPg0K PlRoaXMgZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgaXMgY29uZmlkZW50aWFsIGFuZCBtYXkg Y29udGFpbiBwcml2aWxlZ2VkDQo+aW5mb3JtYXRpb24gaW50ZW5kZWQgZm9yIHRoZSBhZGRyZXNz ZWUocykgb25seS4gRGlzc2VtaW5hdGlvbiwgY29weWluZywNCj5wcmludGluZyBvciB1c2UgYnkg YW55Ym9keSBlbHNlIGlzIHVuYXV0aG9yaXNlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVk DQo+cmVjaXBpZW50LCBwbGVhc2UgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1l bnRzIGFuZCBhZHZpc2UgdGhlDQo+c2VuZGVyIGJ5IHJldHVybiBlLW1haWwsIFRoYW5rcy4NCg0K From jiangsheng@huawei.com Sun Nov 18 19:04: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 22CFC21F85AE; Sun, 18 Nov 2012 19:04:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.479 X-Spam-Level: X-Spam-Status: No, score=-6.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 qgvChnhR3Q-z; Sun, 18 Nov 2012 19:04:29 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5573621F8596; Sun, 18 Nov 2012 19:04:28 -0800 (PST) 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 AMX53423; Mon, 19 Nov 2012 03:04:23 +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, 19 Nov 2012 03:03:57 +0000 Received: from SZXEML423-HUB.china.huawei.com (10.82.67.162) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 19 Nov 2012 11:04:22 +0800 Received: from szxeml545-mbx.china.huawei.com ([169.254.1.6]) by szxeml423-hub.china.huawei.com ([10.82.67.162]) with mapi id 14.01.0323.003; Mon, 19 Nov 2012 11:04:15 +0800 From: Sheng Jiang To: Ted Lemon , Mark Smith Thread-Topic: [v6ops] some feedback on http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-01 Thread-Index: AQHNxAAG5EreTzevi0GNq9gcFwidkJfwdtFw Date: Mon, 19 Nov 2012 03:03:32 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B9239F8ED16@szxeml545-mbx.china.huawei.com> References: <50A33EFA.7070008@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8E40C@szxeml545-mbx.china.huawei.com> <50A59C1F.2040407@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8E520@szxeml545-mbx.china.huawei.com> <50A5BB8E.6010308@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8E5CB@szxeml545-mbx.china.huawei.com> <1353047488.86944.YahooMailNeo@web32501.mail.mud.yahoo.com> <8D23D4052ABE7A4490E77B1A012B630747408741@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630747408741@mbx-01.win.nominum.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.140] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: joel jaeggli , "dhcwg@ietf.org" , IPv6 Ops WG , "draft-ietf-dhc-addr-registration@tools.ietf.org" Subject: Re: [dhcwg] [v6ops] some feedback on http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-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, 19 Nov 2012 03:04:30 -0000 Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogVGVkIExlbW9uIFttYWlsdG86VGVk LkxlbW9uQG5vbWludW0uY29tXQ0KPlNlbnQ6IEZyaWRheSwgTm92ZW1iZXIgMTYsIDIwMTIgOTo0 MSBQTQ0KPlRvOiBNYXJrIFNtaXRoDQo+Q2M6IFNoZW5nIEppYW5nOyBqb2VsIGphZWdnbGk7IGRo Y3dnQGlldGYub3JnOyBJUHY2IE9wcyBXRzsNCj5kcmFmdC1pZXRmLWRoYy1hZGRyLXJlZ2lzdHJh dGlvbkB0b29scy5pZXRmLm9yZw0KPlN1YmplY3Q6IFJlOiBbdjZvcHNdIHNvbWUgZmVlZGJhY2sg b24NCj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWRoYy1hZGRyLXJlZ2lz dHJhdGlvbi0wMQ0KPg0KPk9uIE5vdiAxNiwgMjAxMiwgYXQgMTozMSBBTSwgTWFyayBTbWl0aCA8 bWFya3p6enNtaXRoQHlhaG9vLmNvbS5hdT4NCj53cm90ZToNCj4+IEkgYWdyZWUgd2l0aCBKb2Vs LCBJIHRoaW5rIG9ic2VydmF0aW9uIGJ5IG1vc3QgbGlrZWx5IGEgcm91dGVyIGlzIGEgYmV0dGVy DQo+bWV0aG9kLCBhcyBpdCB3aWxsIGNhcHR1cmUgYWRkcmVzcyBpbmZvcm1hdGlvbiByZWdhcmRs ZXNzIG9mIHdoZXRoZXIgaXQgd2FzDQo+Y29uZmlndXJlZCB2aWEgc3RhdGljLCBTTEFBQyBvciBE SENQdjYgKG9yIGFueSBmdXR1cmUgbWV0aG9kcykuDQo+DQo+SXQncyBjZXJ0YWlubHkgdHJ1ZSB0 aGF0IGEgcm91dGVyIGNhbiBjYXB0dXJlIGFsbCB0aGUgSVB2NCBhbmQgSVB2NiBhZGRyZXNzZXMN Cj50aGF0IGEgZGV2aWNlIHdpdGggYSBwYXJ0aWN1bGFyIE1BQyBhZGRyZXNzIHVzZXMuICAgSG93 ZXZlciwgd2hhdCBhIHJvdXRlcg0KPl9jYW4ndF8gZG8sIGFuZCB3aGF0IHRoaXMgb3B0aW9uIGFs bG93cyB0byBiZSBkb25lLCBpcyBmb3IgYSBkZXZpY2UgdGhhdCBoYXMNCj5hdXRvY29uZmlndXJl ZCB0byB0aGVuIHByb3ZpZGUgdGhlIG5ldHdvcmsgYWRtaW5pc3RyYXRvciB3aXRoIGEgaGludCBh cyB0bw0KPndoYXQgaXRzIEZRRE4gc2hvdWxkIGJlLiAgIFRoaXMgaW5mb3JtYXRpb24gaXNuJ3Qg YXZhaWxhYmxlIHRvIHRoZSByb3V0ZXIuDQo+DQo+SXQgc2VlbXMgdG8gbWUgdGhhdCBhbHRob3Vn aCBpdCBpcyB0cnVlIHRoYXQgaXQgaXMgd29ydGh3aGlsZSB0byBkZWZpbmUgYQ0KPm1lY2hhbmlz bSBmb3IgZ2V0dGluZyBjb21tb24gYWRkcmVzcyBpbmZvcm1hdGlvbiBmcm9tIGEgcm91dGVyLCB0 aGlzIGlzDQo+b3J0aG9nb25hbCB0byB0aGUgcXVlc3Rpb24gb2Ygd2hldGhlciBhIGNsaWVudC1i YXNlZCBtZWNoYW5pc20gZm9yIGFkZHJlc3MNCj5yZWdpc3RyYXRpb24gaXMgdXNlZnVsLiAgIEl0 IHNlZW1zIHRvIG1lIHRoYXQgdGhlcmUgYXJlIHRocmVlIGJyb2FkDQo+Y2xhc3NpZmljYXRpb25z IG9mIHVzZSBjYXNlcyBoZXJlOg0KPg0KPjEuIEluIGFuIGVudmlyb25tZW50IHdoZXJlIGFkZHJl c3MgcmVnaXN0cmF0aW9uIGlzIG1hbmRhdG9yeSwgYW5kIGhvc3RzIGFyZQ0KPnRpZ2h0bHkgY29u dHJvbGxlZCwgdGhpcyBwcm90b2NvbCBtYXkgc3VmZmljZS4NCj4yLiBJbiBhbiBlbnZpcm9ubWVu dCB3aGVyZSBhZGRyZXNzIHJlZ2lzdHJhdGlvbiBpcyBvcHRpb25hbC9hZHZpc29yeSwgdGhpcw0K PnByb3RvY29sIG1heSBzdWZmaWNlLCBzaW5jZSBwcmVzdW1hYmx5IHRoZSByZWFzb24geW91IHJl Z2lzdGVyIGFkZHJlc3NlcyBpcyB0bw0KPnRyYWNrIGNsaWVudC1zb3VyY2VkIGluZm9ybWF0aW9u IGxpa2UgaG9zdG5hbWUgdGhhdCByZWxhdGVzIHRvIHRoZSBhZGRyZXNzLg0KPjMuIEluIGFuIGVu dmlyb25tZW50IHdoZXJlIGFkZHJlc3MgcmVnaXN0cmF0aW9uIGlzIG1hbmRhdG9yeSBhbmQgaG9z dHMgYXJlDQo+bm90IHRpZ2h0bHkgY29udHJvbGxlZCwgeW91IG5lZWQgc3VwcG9ydCBmb3IgYWRk cmVzcyByZWdpc3RyYXRpb24gb24gdGhlIHJvdXRlci4NCj5Ib3dldmVyLCB5b3UgY2FuIF9zdGls bF8gYmVuZWZpdCBpbiB0aGlzIGNhc2UgZnJvbSB0aGUgREhDUC1iYXNlZCBhZGRyZXNzDQo+cmVn aXN0cmF0aW9uIHByb3RvY29sOyBkZXZpY2VzIHRoYXQgc3VwcG9ydCBpdCBjYW4gc3RpbGwgcHJv dmlkZSBoaW50cyBhYm91dCB0aGUNCj5GUUROIHRoZXkgd2FudC4NCj4NCj5JIHBvaW50IHRoaXMg b3V0IGJlY2F1c2UgdGhlIHJlYXNvbiBJIHN1cHBvcnQgdGhpcyBkcmFmdCBpcyB0aGUgRlFETiB1 c2UgY2FzZS4NCj5UaGlzIGlzIGEgdXNlIGNhc2UgdGhhdCBoYXMgc2VlbiBzdWJzdGFudGlhbCB1 c2UgaW4gZW50ZXJwcmlzZSBlbnZpcm9ubWVudHMgaW4NCj5JUHY0LiAgIFdlIGRvIG5vdCBjdXJy ZW50bHkgaGF2ZSBhIHNvbHV0aW9uIHRvIHRoZSBwcm9ibGVtIGZvciBJUHY2LCBiZWNhdXNlDQo+ aW4gSVB2NiB3ZSBkb24ndCByZXF1aXJlIERIQ1AgZm9yIGhvc3QgY29uZmlndXJhdGlvbi4gICBU aGlzIERIQ1AgZXh0ZW5zaW9uDQo+YWxsb3dzIHVzIHRvIGxldmVyYWdlIGEgREhDUCBpbmZyYXN0 cnVjdHVyZSB3aXRob3V0IF9yZXF1aXJpbmdfIHRoYXQgaG9zdHMNCj5hdXRvY29uZmlndXJlIHVz aW5nIERIQ1AsIGFuZCB3aXRob3V0IGV2ZW4gX3JlcXVpcmluZ18gdGhhdCBob3N0cyByZWdpc3Rl cg0KPnRoZWlyIGFkZHJlc3NlcyBhdCBhbGwuDQo+DQo+SSB0aGluayBTaGVuZyBoYXMgYSBkaWZm ZXJlbnQgdXNlIGNhc2UgaW4gbWluZCwgYW5kIGZyb20gd2hhdCBJIGNhbiB0ZWxsIGhpcyB1c2UN Cj5jYXNlIGZhbGxzIGludG8gdGhlIGZpcnN0IGNhdGVnb3J5LCB3aGVyZSBtaW5lIGZhbGxzIGlu dG8gdGhlIHNlY29uZC4gICBJIGtub3cNCj5vZiBvdGhlciBlbnRlcnByaXNlIHVzZXJzIHdobyBo YXZlIHVzZSBjYXNlcyB0aGF0IGZhbGwgaW50byBjYXRlZ29yeSAzOyBmb3INCj50aGVtLCB0aGlz IHByb3RvY29sIHdpbGwgbm90IGJlIHN1ZmZpY2llbnQsIGFuZCB0aGV5IHdpbGwgbmVlZCB0aGUg cm91dGVyLWJhc2VkDQo+cHJvdG9jb2wgZWl0aGVyIGluc3RlYWQsIG9yIGFzIHdlbGwuDQoNCkhp LCBUZWQsDQoNClRoYW5rcyBmb3IgeW91ciBlbWFpbC4gWWVzLCBteSBvcmlnaW5hbCB1c2UgY2Fz ZSBmYWxscyBpbnRvIHRoZSBmaXJzdCBjYXRlZ29yeS4gSG93ZXZlciwgc2luY2Ugd2UgYXJlIHRy eWluZyB0byBkZWZpbmUgYSBnZW5lcmljIGFkZHIgcmVnaXN0cmF0aW9uIG1lY2hhbmlzbSwgd2Ug Y291bGQgaW5jbHVkZSBtb3JlIGFwcGxpY2FibGUgdXNlIGNhc2VzLiBJIGd1ZXNzIHdoYXQgd2Ug c2hvdWxkIGRvIG5vdyBpcyB0byBhZGQgYSAiQXBwbGljYWJpbGl0eSIgc2VjdGlvbiBpbnRvIHRo ZSBkcmFmdC4gQXJlIHlvdSBpbnRlcmVzdGVkIGFuZCBoYXZlIHRpbWUgdG8gY29udHJpYnV0ZSBz b21lIHRleHQ/DQoNCkZvciBtZSwgcm91dGVyLWJhc2VkIGFkZHIgcmVnaXN0cmF0aW9uIG1heSBu ZWVkIGFub3RoZXIgZGVkaWNhdGVkIGRyYWZ0LiBBbHRob3VnaCBjdXJyZW50IElBIGNhbiB3b3Jr IG91dCwgYSBuZXcgREhDUCBvcHRpb24gdGhhdCBzdXBwb3J0IGJ1bGsgYWRkciByZWdpc3RyYXRp b24gbWF5IGJlIG1vcmUgZWZmaWNpZW50IHRoYW4gb25lIGFkZHIgcGVyIHRpbWUuIFdoYXQncyB5 b3VyIG9waW5pb24/DQoNCkJlc3QgcmVnYXJkcywNCg0KU2hlbmcNCg== From Ted.Lemon@nominum.com Sun Nov 18 19:14: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 2AE4E21F85D9; Sun, 18 Nov 2012 19:14:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.582 X-Spam-Level: X-Spam-Status: No, score=-106.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 ahS2PTJlyHAk; Sun, 18 Nov 2012 19:14:14 -0800 (PST) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id E3B4721F85D6; Sun, 18 Nov 2012 19:14:12 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKUKmkBCCvqyWxevgBXRUDaRrapNoeoAD/@postini.com; Sun, 18 Nov 2012 19:14:13 PST 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 247941B80A9; Sun, 18 Nov 2012 19:14:12 -0800 (PST) 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 186FD190043; Sun, 18 Nov 2012 19:14:12 -0800 (PST) (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.0318.004; Sun, 18 Nov 2012 19:14:12 -0800 From: Ted Lemon To: Sheng Jiang Thread-Topic: [dhcwg] [v6ops] some feedback on http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-01 Thread-Index: AQHNxgKaF9DIw6/Nnk+UmCfAcna/WpfxAfqA Date: Mon, 19 Nov 2012 03:14:10 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63074740B8A9@mbx-01.win.nominum.com> References: <50A33EFA.7070008@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8E40C@szxeml545-mbx.china.huawei.com> <50A59C1F.2040407@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8E520@szxeml545-mbx.china.huawei.com> <50A5BB8E.6010308@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8E5CB@szxeml545-mbx.china.huawei.com> <1353047488.86944.YahooMailNeo@web32501.mail.mud.yahoo.com> <8D23D4052ABE7A4490E77B1A012B630747408741@mbx-01.win.nominum.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8ED16@szxeml545-mbx.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B9239F8ED16@szxeml545-mbx.china.huawei.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: joel jaeggli , "dhcwg@ietf.org" , Mark Smith , IPv6 Ops WG , "draft-ietf-dhc-addr-registration@tools.ietf.org" Subject: Re: [dhcwg] [v6ops] some feedback on http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-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, 19 Nov 2012 03:14:15 -0000 On Nov 18, 2012, at 10:03 PM, Sheng Jiang wrote: > Thanks for your email. Yes, my original use case falls into the first cat= egory. However, since we are trying to define a generic addr registration m= echanism, we could include more applicable use cases. I guess what we shoul= d do now is to add a "Applicability" section into the draft. Are you intere= sted and have time to contribute some text? I can try. I have a lot of things on my list. :} > For me, router-based addr registration may need another dedicated draft. = Although current IA can work out, a new DHCP option that support bulk addr = registration may be more efficient than one addr per time. What's your opin= ion? I think that bulk registration won't work because hosts aren't discovered a= ll at the same time; either the router waits until it's accumulated enough = to fill a packet, or it sends an update each time it discovers a new one. From jiangsheng@huawei.com Sun Nov 18 21:59: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 83E7521F8B32 for ; Sun, 18 Nov 2012 21:59:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.099, 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 p2esKWGS48jP for ; Sun, 18 Nov 2012 21:59:26 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6D5B721F874F for ; Sun, 18 Nov 2012 21:59:25 -0800 (PST) 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 ALR55885; Mon, 19 Nov 2012 05:59:23 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 19 Nov 2012 05:58:39 +0000 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, 19 Nov 2012 05:59:02 +0000 Received: from szxeml545-mbx.china.huawei.com ([169.254.1.6]) by SZXEML414-HUB.china.huawei.com ([10.82.67.153]) with mapi id 14.01.0323.003; Mon, 19 Nov 2012 13:58:58 +0800 From: Sheng Jiang To: Sten Carlsen , Ted Lemon Thread-Topic: [dhcwg] [v6ops] some feedback on http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-01 Thread-Index: AQHNxChAznPYYr/3gEmAZiGEQAvg/Zfwqn3w Date: Mon, 19 Nov 2012 05:58:58 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B9239F8EDA3@szxeml545-mbx.china.huawei.com> References: <50A33EFA.7070008@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8E40C@szxeml545-mbx.china.huawei.com> <50A59C1F.2040407@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8E520@szxeml545-mbx.china.huawei.com> <50A5BB8E.6010308@bogus.com> <50A60934.5090507@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B6307474087B8@mbx-01.win.nominum.com> <50A685D7.5030507@s-carlsen.dk> In-Reply-To: <50A685D7.5030507@s-carlsen.dk> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.140] Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B9239F8EDA3szxeml545mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "" Subject: Re: [dhcwg] [v6ops] some feedback on http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-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, 19 Nov 2012 05:59:27 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B9239F8EDA3szxeml545mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIFN0ZW4sDQoNClRoYW5rcyBmb3IgeW91ciBpbnRlcmVzdHMgYW5kIGVtYWlsLiBBY3R1YWxs eSwgdGhlIGRyYWZ0IGRvZXMgdGFyZ2V0IHNvbWUgc2NlbmFyaW8gY2xvc2UgdG8gIzMsIGJ1dCBy ZXBsYWNlIFNPSE8gcm91dGVyIGJ5IGVudGVycHJpc2Ugcm91dGVyLCBJU1AgZWRnZSByb3V0ZXIs IG9yIGhvdHNwb3Qgcm91dGVyLiBUaGVzZSByb3V0ZXJzIGFkdmVydGlzZSBwcmVmaXhlcy4gVGhl IGFkZHIgcmVnaXN0cmF0aW9uIHNlcnZlciBtYXkgYmUgbG9jYXRlZCBzb21ld2hlcmUgaW4gYSBv ciBiLg0KDQpUaGUgbGFuZ3VhZ2UgcHJvYmxlbSBoYXMgYmVlbiByZWNvcmRlZCBhbmQgd2lsbCBi ZSBpbXByb3ZlZCBpbiBuZXh0IHVwZGF0ZS4NCg0KTWFueSB0aGFua3MgYW5kIGJlc3QgcmVnYXJk cywNCg0KU2hlbmcNCg0KRnJvbTogZGhjd2ctYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmRoY3dn LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTdGVuIENhcmxzZW4NClNlbnQ6IFNhdHVy ZGF5LCBOb3ZlbWJlciAxNywgMjAxMiAyOjI5IEFNDQpUbzogVGVkIExlbW9uDQpDYzogPGRoY3dn QGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtkaGN3Z10gW3Y2b3BzXSBzb21lIGZlZWRiYWNrIG9u IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZGhjLWFkZHItcmVnaXN0cmF0 aW9uLTAxDQoNCkkgc2VlIHRoaXMgZG9jdW1lbnQgaXMgcmVhbGx5IGRlc2NyaWJpbmcgYSB0aWdo dGx5IGNvbnRyb2xsZWQgc2V0dXAsIHdoZXJlYXMgSSB3YXMgbG9va2luZyBmb3IgYSBraW5kIG9m IHR3by10aWVyIG1hbmFnZW1lbnQgc2V0dXAuDQoNCkkgd2FzIGNvbmNlcm5lZCB3aXRoIGhvdyBp dCB3b3VsZCB3b3JrIGluIHRoZSBmb2xsb3dpbmcgc2V0dXA6DQoNCkludGVybmV0IC0tYS0tIElT UCAtLWItLSBTT0hPIC0tYy0tIGEgbnVtYmVyIG9mIGhvc3RzDQoNCkluIGxpbmsgImEiIHRoZSBJ U1AgaXMgZ2l2ZW4gYSBsYXJnZSBhZGRyZXNzIGFyZWEgZnJvbSBJQU5BIG9uZSBvciBtb3JlIC80 OCBwcmVmaXhlcy4NCkluIGxpbmsgImIiIHRoZSBJU1AgaGFuZHMgb25lIC82NCBwcmVmaXggb24g dG8gYSBzbWFsbCBjb21wYW55LCAoU09ITykgdGhlc2UgYWRkcmVzc2VzIHNob3VsZCBiZSBnaXZl biBvdXQgdG8gdGhlIHZhcmlvdXMgaG9zdHMgaW4gdGhlIFNPSE8gbmV0d29yayBhbmQgdGhlaXIg bmFtZXMvSVBzIHNob3VsZCBiZSByZWdpc3RlcmVkIGluIHRoZSBTT0hPJ3Mgb3duIEROUyBhbmQg bm90IGJlIHJlZ2lzdGVyZWQgaW4gdGhlIElTUCdzIEROUyBidXQgcG90ZW50aWFsbHkgaW4gdGhl IHJvdXRlciBhY2Nlc3MgdGFibGVzIHRvIGJlIGFsbG93ZWQgb3V0Lg0KTGluayAiYyIgaXMgdGhl IFNPSE8gaW50ZXJuYWwgbmV0d29yaywgdGhpcyBzaG91bGQgYmUgY29udHJvbGxlZCBzb2xlbHkg YnkgdGhlIFNPSE8uDQoNClNvIGdpdmVuIG15IGxldmVsIG9mIHVuZGVyc3RhbmRpbmcgaGVyZSBJ IHdvdWxkIGxpa2UgdG8gYXNrIHdoZXJlIHlvdSBzZWUgdGhpcyBkcmFmdCB1c2VkPw0KMSAtIElz IGl0IHVzZWQgYnkgdGhlIElTUCB0byBjb250cm9sIHRoZSBTT0hPIGhvc3RzLCBJIHRoaW5rIHRo YXQgaXMgbm90IGEgZ29vZCBzb2x1dGlvbi4NCjIgLSBJcyBpdCB1c2VkIGJ5IHRoZSBTT0hPIHRv IGNvbnRyb2wgaGlzIG93biBob3N0cywgdGhhdCB3b3VsZCBiZSBmaW5lLCBleGNlcHQgaWYgdGhl IElTUCBuZWVkcyB0byBrbm93IHdoaWNoIGhvc3RzIGFyZSBhbGxvd2VkIHRvIGFjY2VzcyB0aGUg aW50ZXJuZXQuDQozIC0gSXMgaXQgdXNlZCBvbiBsaW5rICJiIiBvbmx5IHRvIGNvbnRyb2wgdGhl IHJvdXRlciBhdCB0aGUgZWRnZSBvZiB0aGUgU09ITyBhbmQga2VlcCB0cmFjayBvZiB0aGUgSVNQ cyBvd24gbmV0d29yayB1bml0cz8NCg0KSSBiZWxpZXZlICMzIG9uIG15IGxpc3QgaXMgdGhlIGJl c3QgcGxhY2UgdG8gdXNlIHRoaXMgbmV3IGNhcGFiaWxpdHksICMyIGlzIGFsc28gdmVyeSBtdWNo IGluIGxpbmUgd2l0aCB0aGUgZ29hbHMgYW5kIGludGVudGlvbnMgb2YgYSB3ZWxsIG1hbmFnZWQg U09ITy4NCg0KRnJvbSBteSByZWFkaW5nIGl0IGxvb2tzIGxpa2UgaXMgaXMgbXVjaCBtb3JlIGdl YXJlZCB0b3dhcmRzICMxLCB3aGljaCBJIGZlZWwgd291bGQgYmUgYSBiaWcgbWlzdGFrZS4gSXQg d291bGQgcHJldmVudCB0aGUgU09ITyBmcm9tIGFjdHVhbGx5IG1hbmFnaW5nIHRoZWlyIG93biBo b3N0cy4NCg0KQXMgbWVudGlvbmVkIGJlZm9yZSBJIGNhbiBlYXNpbHkgaGF2ZSBtaXNzZWQgb25l IHBvaW50IGhlcmUgb3IgbWF5YmUgdGhpcyBkb2N1bWVudCBpcyBub3Qgc3VpdGVkIHRvIGJlIHVz ZWQgaW4gdGhpcyBzaXR1YXRpb24gYnV0IHNvbWUgb3RoZXIgZG9jdW1lbnQgaXMgd3JpdHRlbiB0 byBjb3ZlciB0aGlzIHNpdHVhdGlvbi4NCg0KSSBmb3VuZCBhIGxhbmd1YWdlIHByb2JsZW0sIEkg YmVsaWV2ZS4gQXQgdGhlIGVuZCBvZiBjaGFwdGVyIDMgSSBmaW5kIHRoaXMgcGFyYWdyYXBoLCB3 aGljaCBJIHRoaW5rIG5lZWRzIGEgYml0IHR3ZWFraW5nOg0KDQogQnkgcmVjZWl2ZWQgdGhlIGFj a25vd2xlZGdlbWVudCwgdGhlIGhvc3QgY2FuIGNvbnRpbnVlIHVzZSB0aGUNCg0KICAgcmVnaXN0 ZXJlZCBhZGRyZXNzLiAgSXQgU0hPVUxEIHVzZSB0aGUgYXNzaWduZWQgcHJlZmVycmVkIGFuZCB2 YWxpZA0KDQogICBsaWZldGltZSBmb3IgdGhlIGNvcnJlc3BvbmRlZGluZyBhZGRyZXNzLg0KDQoN Ck9uIDE2LzExLzEyIDE0OjQ1LCBUZWQgTGVtb24gd3JvdGU6DQoNCk9uIE5vdiAxNiwgMjAxMiwg YXQgNDozNiBBTSwgU3RlbiBDYXJsc2VuIDxzdGVuY0BzLWNhcmxzZW4uZGs+PG1haWx0bzpzdGVu Y0BzLWNhcmxzZW4uZGs+IHdyb3RlOg0KDQpUaGlzIGxlYWRzIHRvIG15IHF1ZXN0aW9uOiBpcyB0 aGlzIHNldHVwIHRha2VuIGludG8gYWNjb3VudCBwcmVzZW50bHk/IElzIHRoZXJlIGEgY2xlYXIg Y3V0IGluIHRoZSBzeXN0ZW0gYWxsb3dpbmcgZm9yIHRoaXMgZGl2aXNpb24uICBJIHNob3VsZCBi ZSBhYmxlIHRvIHJlYWQgdGhpcyBteXNlbGYgYnV0IHRpbWUgaGFzIG5vdCBhbGxvd2VkIGZvciB0 aGF0IGFuZCBJIGhhdmUgbm90IHNlZW4gdGhpcyBpbiB0aGUgZGlzY3Vzc2lvbnMuDQoNCg0KDQpJ dCdzIGEgc3BlY2lmaWMgaW50ZW50IG9mIHRoZSBESEMgd29ya2luZyBncm91cCB0aGF0IHRoaXMg ZG9jdW1lbnQgY292ZXIgdGhlIERIQ1AvRE5TIHVwZGF0ZSB1c2UgY2FzZS4gICBJdCB3b3VsZCBi ZSBnb29kIGlmIHlvdSBjb3VsZCByZWFkIHRoZSBkb2N1bWVudCBhbmQgYXNzdXJlIHlvdXJzZWxm IHRoYXQgaXQgZG9lcyBpbiBmYWN0IGNvdmVyIHRoYXQgY2FzZeKAlG1vcmUgcmV2aWV3IGlzIGFs d2F5cyBiZXR0ZXIuDQoNCg0KDQoNCg0KLS0NCg0KQmVzdCByZWdhcmRzDQoNCg0KDQpTdGVuIENh cmxzZW4NCg0KDQoNCk5vIGltcHJvdmVtZW50cyBjb21lIGZyb20gc2hvdXRpbmc6DQoNCg0KDQog ICAgICAgIk1BTEUgQk9WSU5FIE1BTlVSRSEhISINCg== --_000_5D36713D8A4E7348A7E10DF7437A4B9239F8EDA3szxeml545mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0K YTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29s b3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5N c29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVy cGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCDpooTorr7moLzlvI8gQ2hhciI7DQoJbWFy Z2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTENoYXIN Cgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwg6aKE6K6+5qC85byPIENoYXIiOw0KCW1zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCDpooTorr7moLzlvI8iOw0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcy LjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSIjRkZGRkNDIiBsYW5nPSJaSC1DTiIgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5IaSwgU3Rlbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ VGhhbmtzIGZvciB5b3VyIGludGVyZXN0cyBhbmQgZW1haWwuIEFjdHVhbGx5LCB0aGUgZHJhZnQg ZG9lcyB0YXJnZXQgc29tZSBzY2VuYXJpbyBjbG9zZSB0byAjMywgYnV0IHJlcGxhY2UgU09ITyBy b3V0ZXIgYnkgZW50ZXJwcmlzZSByb3V0ZXIsIElTUA0KIGVkZ2Ugcm91dGVyLCBvciBob3RzcG90 IHJvdXRlci4gVGhlc2Ugcm91dGVycyBhZHZlcnRpc2UgcHJlZml4ZXMuIFRoZSBhZGRyIHJlZ2lz dHJhdGlvbiBzZXJ2ZXIgbWF5IGJlIGxvY2F0ZWQgc29tZXdoZXJlIGluIGEgb3IgYi48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIGxhbmd1YWdlIHByb2JsZW0gaGFzIGJl ZW4gcmVjb3JkZWQgYW5kIHdpbGwgYmUgaW1wcm92ZWQgaW4gbmV4dCB1cGRhdGUuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk1hbnkgdGhhbmtzIGFuZCBiZXN0IHJlZ2FyZHMs PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNoZW5nPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3Bh ZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNt Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiBkaGN3Zy1ib3Vu Y2VzQGlldGYub3JnIFttYWlsdG86ZGhjd2ctYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFs ZiBPZiA8L2I+U3RlbiBDYXJsc2VuPGJyPg0KPGI+U2VudDo8L2I+IFNhdHVyZGF5LCBOb3ZlbWJl ciAxNywgMjAxMiAyOjI5IEFNPGJyPg0KPGI+VG86PC9iPiBUZWQgTGVtb248YnI+DQo8Yj5DYzo8 L2I+ICZsdDtkaGN3Z0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtkaGN3 Z10gW3Y2b3BzXSBzb21lIGZlZWRiYWNrIG9uIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtZGhjLWFkZHItcmVnaXN0cmF0aW9uLTAxPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5JIHNlZSB0aGlzIGRvY3Vt ZW50IGlzIHJlYWxseSBkZXNjcmliaW5nIGEgdGlnaHRseSBjb250cm9sbGVkIHNldHVwLCB3aGVy ZWFzIEkgd2FzIGxvb2tpbmcgZm9yIGEga2luZCBvZiB0d28tdGllciBtYW5hZ2VtZW50IHNldHVw Ljxicj4NCjxicj4NCkkgd2FzIGNvbmNlcm5lZCB3aXRoIGhvdyBpdCB3b3VsZCB3b3JrIGluIHRo ZSBmb2xsb3dpbmcgc2V0dXA6PGJyPg0KPGJyPg0KSW50ZXJuZXQgLS1hLS0gSVNQIC0tYi0tIFNP SE8gLS1jLS0gYSBudW1iZXIgb2YgaG9zdHM8YnI+DQo8YnI+DQpJbiBsaW5rICZxdW90O2EmcXVv dDsgdGhlIElTUCBpcyBnaXZlbiBhIGxhcmdlIGFkZHJlc3MgYXJlYSBmcm9tIElBTkEgb25lIG9y IG1vcmUgLzQ4IHByZWZpeGVzLjxicj4NCkluIGxpbmsgJnF1b3Q7YiZxdW90OyB0aGUgSVNQIGhh bmRzIG9uZSAvNjQgcHJlZml4IG9uIHRvIGEgc21hbGwgY29tcGFueSwgKFNPSE8pIHRoZXNlIGFk ZHJlc3NlcyBzaG91bGQgYmUgZ2l2ZW4gb3V0IHRvIHRoZSB2YXJpb3VzIGhvc3RzIGluIHRoZSBT T0hPIG5ldHdvcmsgYW5kIHRoZWlyIG5hbWVzL0lQcyBzaG91bGQgYmUgcmVnaXN0ZXJlZCBpbiB0 aGUgU09ITydzIG93biBETlMgYW5kIG5vdCBiZSByZWdpc3RlcmVkIGluIHRoZSBJU1AncyBETlMg YnV0IHBvdGVudGlhbGx5DQogaW4gdGhlIHJvdXRlciBhY2Nlc3MgdGFibGVzIHRvIGJlIGFsbG93 ZWQgb3V0Ljxicj4NCkxpbmsgJnF1b3Q7YyZxdW90OyBpcyB0aGUgU09ITyBpbnRlcm5hbCBuZXR3 b3JrLCB0aGlzIHNob3VsZCBiZSBjb250cm9sbGVkIHNvbGVseSBieSB0aGUgU09ITy48YnI+DQo8 YnI+DQpTbyBnaXZlbiBteSBsZXZlbCBvZiB1bmRlcnN0YW5kaW5nIGhlcmUgSSB3b3VsZCBsaWtl IHRvIGFzayB3aGVyZSB5b3Ugc2VlIHRoaXMgZHJhZnQgdXNlZD88YnI+DQoxIC0gSXMgaXQgdXNl ZCBieSB0aGUgSVNQIHRvIGNvbnRyb2wgdGhlIFNPSE8gaG9zdHMsIEkgdGhpbmsgdGhhdCBpcyBu b3QgYSBnb29kIHNvbHV0aW9uLjxicj4NCjIgLSBJcyBpdCB1c2VkIGJ5IHRoZSBTT0hPIHRvIGNv bnRyb2wgaGlzIG93biBob3N0cywgdGhhdCB3b3VsZCBiZSBmaW5lLCBleGNlcHQgaWYgdGhlIElT UCBuZWVkcyB0byBrbm93IHdoaWNoIGhvc3RzIGFyZSBhbGxvd2VkIHRvIGFjY2VzcyB0aGUgaW50 ZXJuZXQuPGJyPg0KMyAtIElzIGl0IHVzZWQgb24gbGluayAmcXVvdDtiJnF1b3Q7IG9ubHkgdG8g Y29udHJvbCB0aGUgcm91dGVyIGF0IHRoZSBlZGdlIG9mIHRoZSBTT0hPIGFuZCBrZWVwIHRyYWNr IG9mIHRoZSBJU1BzIG93biBuZXR3b3JrIHVuaXRzPzxicj4NCjxicj4NCkkgYmVsaWV2ZSAjMyBv biBteSBsaXN0IGlzIHRoZSBiZXN0IHBsYWNlIHRvIHVzZSB0aGlzIG5ldyBjYXBhYmlsaXR5LCAj MiBpcyBhbHNvIHZlcnkgbXVjaCBpbiBsaW5lIHdpdGggdGhlIGdvYWxzIGFuZCBpbnRlbnRpb25z IG9mIGEgd2VsbCBtYW5hZ2VkIFNPSE8uPGJyPg0KPGJyPg0KRnJvbSBteSByZWFkaW5nIGl0IGxv b2tzIGxpa2UgaXMgaXMgbXVjaCBtb3JlIGdlYXJlZCB0b3dhcmRzICMxLCB3aGljaCBJIGZlZWwg d291bGQgYmUgYSBiaWcgbWlzdGFrZS4gSXQgd291bGQgcHJldmVudCB0aGUgU09ITyBmcm9tIGFj dHVhbGx5IG1hbmFnaW5nIHRoZWlyIG93biBob3N0cy48YnI+DQo8YnI+DQpBcyBtZW50aW9uZWQg YmVmb3JlIEkgY2FuIGVhc2lseSBoYXZlIG1pc3NlZCBvbmUgcG9pbnQgaGVyZSBvciBtYXliZSB0 aGlzIGRvY3VtZW50IGlzIG5vdCBzdWl0ZWQgdG8gYmUgdXNlZCBpbiB0aGlzIHNpdHVhdGlvbiBi dXQgc29tZSBvdGhlciBkb2N1bWVudCBpcyB3cml0dGVuIHRvIGNvdmVyIHRoaXMgc2l0dWF0aW9u Ljxicj4NCjxicj4NCkkgZm91bmQgYSBsYW5ndWFnZSBwcm9ibGVtLCBJIGJlbGlldmUuIEF0IHRo ZSBlbmQgb2YgY2hhcHRlciAzIEkgZmluZCB0aGlzIHBhcmFncmFwaCwgd2hpY2ggSSB0aGluayBu ZWVkcyBhIGJpdCB0d2Vha2luZzo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cHJlPjxzcGFuIGxh bmc9IkVOLVVTIj4gQnkgcmVjZWl2ZWQgdGhlIGFja25vd2xlZGdlbWVudCwgdGhlIGhvc3QgY2Fu IGNvbnRpbnVlIHVzZSB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFu Zz0iRU4tVVMiPiZuYnNwOyZuYnNwOyByZWdpc3RlcmVkIGFkZHJlc3MuJm5ic3A7IEl0IFNIT1VM RCB1c2UgdGhlIGFzc2lnbmVkIHByZWZlcnJlZCBhbmQgdmFsaWQ8bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyBsaWZldGltZSBmb3Ig dGhlIGNvcnJlc3BvbmRlZGluZyBhZGRyZXNzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy ZT48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9uIDE2LzExLzEyIDE0 OjQ1LCBUZWQgTGVtb24gd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxw cmU+PHNwYW4gbGFuZz0iRU4tVVMiPk9uIE5vdiAxNiwgMjAxMiwgYXQgNDozNiBBTSwgU3RlbiBD YXJsc2VuIDxhIGhyZWY9Im1haWx0bzpzdGVuY0BzLWNhcmxzZW4uZGsiPiZsdDtzdGVuY0BzLWNh cmxzZW4uZGsmZ3Q7PC9hPiB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT48 c3BhbiBsYW5nPSJFTi1VUyI+VGhpcyBsZWFkcyB0byBteSBxdWVzdGlvbjogaXMgdGhpcyBzZXR1 cCB0YWtlbiBpbnRvIGFjY291bnQgcHJlc2VudGx5PyBJcyB0aGVyZSBhIGNsZWFyIGN1dCBpbiB0 aGUgc3lzdGVtIGFsbG93aW5nIGZvciB0aGlzIGRpdmlzaW9uLiZuYnNwOyBJIHNob3VsZCBiZSBh YmxlIHRvIHJlYWQgdGhpcyBteXNlbGYgYnV0IHRpbWUgaGFzIG5vdCBhbGxvd2VkIGZvciB0aGF0 IGFuZCBJIGhhdmUgbm90IHNlZW4gdGhpcyBpbiB0aGUgZGlzY3Vzc2lvbnMuPG86cD48L286cD48 L3NwYW4+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPkl0J3Mg YSBzcGVjaWZpYyBpbnRlbnQgb2YgdGhlIERIQyB3b3JraW5nIGdyb3VwIHRoYXQgdGhpcyBkb2N1 bWVudCBjb3ZlciB0aGUgREhDUC9ETlMgdXBkYXRlIHVzZSBjYXNlLiZuYnNwOyZuYnNwOyBJdCB3 b3VsZCBiZSBnb29kIGlmIHlvdSBjb3VsZCByZWFkIHRoZSBkb2N1bWVudCBhbmQgYXNzdXJlIHlv dXJzZWxmIHRoYXQgaXQgZG9lcyBpbiBmYWN0IGNvdmVyIHRoYXQgY2FzZeKAlG1vcmUgcmV2aWV3 IGlzIGFsd2F5cyBiZXR0ZXIuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjwvYmxvY2txdW90ZT4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8YnI+DQo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4tLSA8bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPkJlc3QgcmVnYXJkczxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5TdGVuIENhcmxzZW48 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Tm8gaW1wcm92 ZW1lbnRzIGNvbWUgZnJvbSBzaG91dGluZzo8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48 c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZx dW90O01BTEUgQk9WSU5FIE1BTlVSRSEhISZxdW90OyA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N CjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_5D36713D8A4E7348A7E10DF7437A4B9239F8EDA3szxeml545mbxchi_-- From jiangsheng@huawei.com Sun Nov 18 22: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 0574521F8471; Sun, 18 Nov 2012 22:27:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.513 X-Spam-Level: X-Spam-Status: No, score=-6.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 rW1GA2T8aoAG; Sun, 18 Nov 2012 22:27:13 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 71E3321F8616; Sun, 18 Nov 2012 22:27:12 -0800 (PST) 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 AMX65672; Mon, 19 Nov 2012 06:27:08 +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, 19 Nov 2012 06:26:41 +0000 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, 19 Nov 2012 06:27:06 +0000 Received: from szxeml545-mbx.china.huawei.com ([169.254.1.6]) by szxeml401-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Mon, 19 Nov 2012 14:27:01 +0800 From: Sheng Jiang To: Tim Chown , "dhcwg@ietf.org" , IPv6 Ops WG , "draft-ietf-dhc-addr-registration@tools.ietf.org" Thread-Topic: [dhcwg] [v6ops] some feedback on http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-01 Thread-Index: AQHNxL3VwLXtCQncR0mp9Eo3CReCeZfwsS2w Date: Mon, 19 Nov 2012 06:27:00 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B9239F8EDD8@szxeml545-mbx.china.huawei.com> References: <50A33EFA.7070008@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8E40C@szxeml545-mbx.china.huawei.com> <50A59C1F.2040407@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8E520@szxeml545-mbx.china.huawei.com> <50A5BB8E.6010308@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8E5CB@szxeml545-mbx.china.huawei.com> <1353047488.86944.YahooMailNeo@web32501.mail.mud.yahoo.com> <8D23D4052ABE7A4490E77B1A012B630747408741@mbx-01.win.nominum.com> <1353109754.80634.YahooMailNeo@web32501.mail.mud.yahoo.com> In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.140] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [dhcwg] [v6ops] some feedback on http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-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, 19 Nov 2012 06:27:14 -0000 Pj4gSSB0aGluayB0aGVyZSBhcmUgYWR2YW50YWdlcyB0byBrZWVwaW5nIHRoZSBtZWNoYW5pc21z IHRvIGNvbGxlY3QNCj5pbmZvcm1hdGlvbg0KPj4gYWJvdXQgaG9zdHMgYW5kIHRoZWlyIGFkZHJl c3NlcyBpbmRlcGVuZGVudCBvZiBob3cgdGhvc2UgYWRkcmVzc2VzIGFyZQ0KPj4gYXNzaWduZWQg b3IgZGVyaXZlZC4NCj4NCj5JIHRoaW5rIHRoaXMgaXMgYSBmYWlyIHBvaW50Lg0KDQpUaW0gYW5k IE1hcmssDQoNCkFsdGhvdWdoIHdlIHVzZWQgREhDUHY2IHByb3RvY29sIHRvIGNhcnJ5IHRoZSBh ZGRyIHJlZ2lzdHJhdGlvbiBpbmZvcm1hdGlvbi4gVGhlIHByb2NlZHVyZSBpcyBub3QgbmVjZXNz YXJ5IHRvIGJlIG1peGVkIHdpdGggdGhlIHdheSB0aG9zZSBhZGRyZXNzZXMgYXJlIGFzc2lnbmVk IG9yIGRlcml2ZWQuIFRoZXkgYXJlIGluZGVwZW5kZW50IG9wZXJhdGlvbnMuDQoNCj5JIGFsc28g Y2FuJ3QgaGVscCBidXQgdGhpbmsgdGhhdCB0aGVyZSBpcyBsaWtlbHkgdG8gYmUgc29tZSBvdmVy bGFwIGJldHdlZW4gd2hhdA0KPnRoaXMgZHJhZnQgaXMgdHJ5aW5nIHRvIGRvLCBhbmQgd2hhdCB3 ZSBtaWdodCBlbmQgdXAgd2l0aCBhcyBhIHJlc3VsdCBvZiB0aGUNCj5ob21lbmV0IGFuZC9vciBt ZG5zZXh0IHdvcmsgaW4gZXh0ZW5kaW5nIHplcm9jb25mIG1ldGhvZHMgdG8gaG9tZSBhbmQNCj5l bnRlcnByaXNlL2NhbXB1cyBuZXR3b3Jrcy4NCg0KSSBkb24ndCB1bmRlcnN0YW5kIHdoeSB3ZSBz aG91bGQgbWFrZSB3YXkgdG8gZnV0dXJlIHdvcmsgd2hpY2ggaGFzIG5vdCBoYXBwZW4geWV0LiBU aGV5IG1heSB1c2Ugb3VyIG91dHB1dCBpZiB0aGVyZSBpcyBvdmVybGFwLg0KDQo+U2ltcGx5IGZv ciBhZGRyZXNzIHVzYWdlIHRyYWNraW5nLCB3ZSd2ZSBmb3VuZCBpdCBzdWZmaWNpZW50IHRvIHJ1 biB0b29scyB0aGF0DQo+cG9sbCB0aGUgc3dpdGNoL3JvdXRlciBpbmZyYXN0cnVjdHVyZS4gV2Ug ZG8gdGhhdCBvbiBhIGNhbXB1cyB1c2luZyBvcGVuDQo+c291cmNlIHRvb2xzIGFuZCBpdCB3b3Jr cyBqdXN0IGZpbmUsIHByb3ZpZGVkIHRoZSBwb2xsaW5nIGlzIGNvbmZpZ3VyZWQgdG8gdGFrZQ0K PmludG8gYWNjb3VudCB0aGUgZXhwaXJhdGlvbiB0aW1lcnMgb2YgdGhlIGRhdGEgYmVpbmcgZ2F0 aGVyZWQgZnJvbSB0aGUNCj5kZXZpY2VzLiBXaGVyZSB0aGUgdG9vbCBpcyBhbHNvIGF3YXJlIG9m IHRoZSBhbGwgdGhlIG5ldHdvcmsgZGV2aWNlcywgdGhlaXINCj5jb25uZWN0aXZpdHksIHByZWZp eCBhbGxvY2F0aW9ucywgVkxBTnMsIHN3aXRjaCBwb3J0IGNvbmZpZ3VyYXRpb25zLCBldGMsIHRo ZW4NCj55b3UgaGF2ZSBwcmV0dHkgbXVjaCBhbGwgeW91IG5lZWQgZm9yIGFjY291bnRhYmlsaXR5 LiBXZSBhbHNvIHVzZSA4MDIuMVggZm9yDQo+d2lyZWxlc3MgKGVkdXJvYW0pIGFuZCBhcmUgYmVn aW5uaW5nIHRvIHVzZSBpdCBmb3Igd2lyZWQgcG9ydHMgYXMgd2VsbC4NCg0KSSBoYXZlIG5vIGRv dWJ0IHRvb2xzIHdpdGggdGhlaXIgcHJpdmF0ZSBwcm90b2NvbCBjYW4gY29tcGxldGUgdGhlIHdv cmsgdG9vLiBIZXJlLCB3ZSBhcmUgdHJ5aW5nIHRvIHVzZSBhIHN0YW5kYXJkIHByb3RvY29sIHRv IGNhcnJ5IHRoZSBpbmZvcm1hdGlvbi4gVGhpcyB3b3VsZCBhbHNvIGJlbmVmaXQgZm9yIHZhcmlv dXMgaW1wbGVtZW50YXRpb25zLg0KDQpCZXN0IHJlZ2FyZHMsDQoNClNoZW5nDQoNCj5JJ3ZlIG5v dCBsb29rZWQgYXQgRmVybmFuZG8ncyB0b29sLiBJIHdvdWxkIGFzc3VtZSBpdCBhY2hpZXZlcyB0 aGUgc2FtZSB0aGluZw0KPmluIHRlcm1zIG9mIGFkZHJlc3MgdHJhY2tpbmcsIGJ1dCBJJ2QgYXJn dWUgdGhhdCBpbnRlZ3JhdGluZyB0aGUgcG9sbGluZy90cmFja2luZw0KPndpdGggbmV0d29yayBt b25pdG9yaW5nL21hbmFnZW1lbnQgdG9vbHMgdGhhdCBoYXZlIHRoZSAnYmlnZ2VyIHBpY3R1cmUn IGlzDQo+YWR2YW50YWdlb3VzLg0KPg0KPlRpbQ0KPl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+ZGhjd2cgbWFpbGluZyBsaXN0DQo+ZGhjd2dAaWV0Zi5v cmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RoY3dnDQo= From jiangsheng@huawei.com Sun Nov 18 22:59: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 3E58321F862B; Sun, 18 Nov 2012 22:59:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 QpZIVoHEWqxP; Sun, 18 Nov 2012 22:59:22 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3434D21F8706; Sun, 18 Nov 2012 22:59:22 -0800 (PST) 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 AMX68527; Mon, 19 Nov 2012 06:59:18 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 19 Nov 2012 06:58:55 +0000 Received: from SZXEML419-HUB.china.huawei.com (10.82.67.158) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 19 Nov 2012 06:59:17 +0000 Received: from szxeml545-mbx.china.huawei.com ([169.254.1.6]) by szxeml419-hub.china.huawei.com ([10.82.67.158]) with mapi id 14.01.0323.003; Mon, 19 Nov 2012 14:59:09 +0800 From: Sheng Jiang To: Ted Lemon Thread-Topic: [dhcwg] [v6ops] some feedback on http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-01 Thread-Index: AQHNxgP73Bu344hO/0adTOoIrKqbXZfwuOHA Date: Mon, 19 Nov 2012 06:59:08 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B9239F8EE40@szxeml545-mbx.china.huawei.com> References: <50A33EFA.7070008@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8E40C@szxeml545-mbx.china.huawei.com> <50A59C1F.2040407@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8E520@szxeml545-mbx.china.huawei.com> <50A5BB8E.6010308@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8E5CB@szxeml545-mbx.china.huawei.com> <1353047488.86944.YahooMailNeo@web32501.mail.mud.yahoo.com> <8D23D4052ABE7A4490E77B1A012B630747408741@mbx-01.win.nominum.com> <5D36713D8A4E7348A7E10DF7437A4B9239F8ED16@szxeml545-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B63074740B8A9@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63074740B8A9@mbx-01.win.nominum.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.140] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: joel jaeggli , "dhcwg@ietf.org" , Mark Smith , IPv6 Ops WG , "draft-ietf-dhc-addr-registration@tools.ietf.org" Subject: Re: [dhcwg] [v6ops] some feedback on http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-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, 19 Nov 2012 06:59:23 -0000 Pj4gRm9yIG1lLCByb3V0ZXItYmFzZWQgYWRkciByZWdpc3RyYXRpb24gbWF5IG5lZWQgYW5vdGhl ciBkZWRpY2F0ZWQgZHJhZnQuDQo+PkFsdGhvdWdoIGN1cnJlbnQgSUEgY2FuIHdvcmsgb3V0LCBh IG5ldyBESENQIG9wdGlvbiB0aGF0IHN1cHBvcnQgYnVsayBhZGRyDQo+PnJlZ2lzdHJhdGlvbiBt YXkgYmUgbW9yZSBlZmZpY2llbnQgdGhhbiBvbmUgYWRkciBwZXIgdGltZS4gV2hhdCdzIHlvdXIN Cj4+b3Bpbmlvbj8NCj4NCj5JIHRoaW5rIHRoYXQgYnVsayByZWdpc3RyYXRpb24gd29uJ3Qgd29y ayBiZWNhdXNlIGhvc3RzIGFyZW4ndCBkaXNjb3ZlcmVkIGFsbCBhdA0KPnRoZSBzYW1lIHRpbWU7 IGVpdGhlciB0aGUgcm91dGVyIHdhaXRzIHVudGlsIGl0J3MgYWNjdW11bGF0ZWQgZW5vdWdoIHRv IGZpbGwgYQ0KPnBhY2tldCwgb3IgaXQgc2VuZHMgYW4gdXBkYXRlIGVhY2ggdGltZSBpdCBkaXNj b3ZlcnMgYSBuZXcgb25lLg0KDQpNYWtlIHNlbnNlLiBTbywgd2Ugd2lsbCBleHBhbmQgdGhlIGN1 cnJlbnQgYWRkciByZWdpc3RyYXRpb24gdG8gYmUgY2xpZW50LWJhc2VkIG1vZGVsLCBpbiB3aGlj aCB0aGUgY2xpZW50IG1heWJlIHJvdXRlci4NCg0KU2hlbmcNCg== From mohamed.boucadair@orange.com Sun Nov 18 23:37: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 A67CF21F87AF for ; Sun, 18 Nov 2012 23:37:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.964 X-Spam-Level: X-Spam-Status: No, score=-1.964 tagged_above=-999 required=5 tests=[AWL=0.284, 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 NowCI99WXoxt for ; Sun, 18 Nov 2012 23:37:54 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id C4B7F21F86F8 for ; Sun, 18 Nov 2012 23:37:53 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 2BF7E2641D5; Mon, 19 Nov 2012 08:37:53 +0100 (CET) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 1218327C066; Mon, 19 Nov 2012 08:37:53 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Mon, 19 Nov 2012 08:37:52 +0100 From: To: Bud Millwood Date: Mon, 19 Nov 2012 08:37:51 +0100 Thread-Topic: [dhcwg] IP address vs. FQDN discussion Thread-Index: Ac3ES5usC9GRuubMQsaiLqHZGN/nqAB3HovA Message-ID: <94C682931C08B048B7A8645303FDC9F36E9751E53D@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E947B0E73@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E95C9F87B@PUEXCB1B.nanterre.francetelecom.fr> 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.11.19.40315 Cc: "" Subject: Re: [dhcwg] IP address vs. FQDN discussion X-BeenThere: dhcwg@ietf.org 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, 19 Nov 2012 07:37:54 -0000 Dear Bud, Please see inline. Cheers, Med=20 >-----Message d'origine----- >De : Bud Millwood [mailto:budmillwood@gmail.com]=20 >Envoy=E9 : vendredi 16 novembre 2012 23:42 >=C0 : BOUCADAIR Mohamed OLNC/OLN >Cc : >Objet : Re: [dhcwg] IP address vs. FQDN discussion > >If I understand this correctly, it's a proposal to allow sending >either a name or ip address encoded as a string? Med: Yes. > >Space in DHCPv4 packets is limited. Encoding an IP address as text is >a huge waste of valuable packet space for that protocol. Med: I don't see this as an issue as fqdn can be conveyed also in a dhcpv4 = option. > >Also, proposing that multiple names be separated with whitespace is >equivalent to either a) introducing a new encoding for sequences or b) >having the option value treated as opaque date. If it's the latter, we >lose the ability to verify that the payload is properly formatted. Med: in -02, we are using length-encoded strings to pack multiple options w= hen needed. > >Some options use a type specifier, 0 or 1, to denote ip address or dns >name. Is there any reason to not use that? Med: dhw wg is not in favor of that design; please refer to http://tools.ie= tf.org/html/draft-ietf-dhc-option-guidelines-08#section-7.=20 > >- Bud > >On Thu, Nov 15, 2012 at 4:04 PM, wrote: >> Dear Erik, >> >> Thanks for reading the draft and also for supporting this proposal. >> >> For information, I have submitted an updated version of the=20 >draft which is available at: >> >>=20 >http://tools.ietf.org/html/draft-boucadair-dhc-address-name-encoding-02 >> >> Comments from WG are more than welcome. >> >> Cheers, >> Med >> >>>-----Message d'origine----- >>>De : Erik Kline [mailto:ek@google.com] >>>Envoy=E9 : jeudi 15 novembre 2012 04:24 >>>=C0 : BOUCADAIR Mohamed OLNC/OLN >>>Cc : >>>Objet : Re: [dhcwg] IP address vs. FQDN discussion >>> >>>After a very cursory reading, I would say largely +1. I'm in favour >>>of something like "a UTF-8 string intended to passed to a=20 >higher layer >>>address resolution mechanism, a la getaddrinfo(), et cetera". >>> >>>On 8 November 2012 07:30, wrote: >>>> Dear all, >>>> >>>> As this question is repeatedly raised, including in the >>>ongoing dhc meeting, >>>> we have edited a draft which proposes an approach which >>>conciliates both >>>> modes: It defines a name option encoded as UTF-8 string >>>which can be a >>>> domain name, IPv4 address literals, etc. The draft is available at: >>>> >>>> >>>http://tools.ietf.org/html/draft-boucadair-dhc-address-name-e >ncoding-01 >>>> >>>> Comments are welcome. >>>> >>>> Cheers, >>>> Med >>>> >>>> >>>> _______________________________________________ >>>> 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 Wed Nov 21 12:54: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 071C921F87BB for ; Wed, 21 Nov 2012 12:54:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.572 X-Spam-Level: X-Spam-Status: No, score=-106.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 0luIIbbpzeJV for ; Wed, 21 Nov 2012 12:54:00 -0800 (PST) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 55FB621F879C for ; Wed, 21 Nov 2012 12:54:00 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKUK0/ZwxL/rVn09EhRE4Y2lqyPi+DuT9g@postini.com; Wed, 21 Nov 2012 12:54:00 PST 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 415EB1B81A1 for ; Wed, 21 Nov 2012 12:53:59 -0800 (PST) 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 38D03190043 for ; Wed, 21 Nov 2012 12:53:59 -0800 (PST) (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.0318.004; Wed, 21 Nov 2012 12:53:53 -0800 From: Ted Lemon To: "dhcwg@ietf.org WG" Thread-Topic: Call for adoption: draft-kostur-dhc-loadbv6 Thread-Index: AQHNyCpQew5U9EycT0KdIO17tnO80A== Date: Wed, 21 Nov 2012 20:53:52 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63074740E9BE@mbx-01.win.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: <1D4EB2873F0FF9439451019708017F30@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dhcwg] Call for adoption: draft-kostur-dhc-loadbv6 X-BeenThere: dhcwg@ietf.org 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, 21 Nov 2012 20:54:01 -0000 Andre has asked if the working group would be willing to adopt his load bal= ancing draft as a working group work item. There's already been some disc= ussion on the mailing list, but we haven't formally taken on the work. T= he draft is here: http://tools.ietf.org/html/draft-kostur-dhc-loadbv6-03 If you think the dhc working group should take on this work, please reply t= o this message and say so. If you think we should not take on this work, = please reply to this message and say so. If you have comments on the draf= t, please discuss on the mailing list. We will evaluate consensus on or after December 5. From akostur@incognito.com Wed Nov 21 13:16: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 20E7821F8861 for ; Wed, 21 Nov 2012 13:16:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 OlFZnNp8M+eF for ; Wed, 21 Nov 2012 13:16:30 -0800 (PST) Received: from na3sys010aog111.obsmtp.com (na3sys010aog111.obsmtp.com [74.125.245.90]) by ietfa.amsl.com (Postfix) with SMTP id 619F421F84C4 for ; Wed, 21 Nov 2012 13:16:30 -0800 (PST) Received: from mail-qa0-f70.google.com ([209.85.216.70]) (using TLSv1) by na3sys010aob111.postini.com ([74.125.244.12]) with SMTP ID DSNKUK1ErV031JruNkoWDe33VzKNMb4WLgH6@postini.com; Wed, 21 Nov 2012 13:16:30 PST Received: by mail-qa0-f70.google.com with SMTP id s11so507571qaa.1 for ; Wed, 21 Nov 2012 13:16:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding:x-gm-message-state; bh=lI9Xk8W6c1yYb3WQ8gKCDpySi/pYH4OArbN15odhuLQ=; b=DPyfKHbMT3rO5Wrho7DB+/vy0HCRScKYoD4EGP/OkJMqmy7mOxJixwCjiDUKQ/+oQz k+TNnl+JH9pya/1eBuxG43Kb8Vi7fAys2fwMLRkB6D3WFRxWccxUUtZFFU1Z+UlbqXqd IU1yJdMy8qeR/roeLpovCCJyZ6xlvLznO078K0TnMkhxUpC1BSR1WCqEOQtkAqMhl57a OWAUxadu9EyLrXP49ZKHt9ZFsNMS5V5Ns8BR3FRU0zuqTVXF2DFwABFFce+Fb4FrbG/6 H4+KxUnCgXsKNKhEGak2ipL5XZTrk3wDCef3g+jJYRKueRiLxUiSF4OWbSr22SL/99He wpVg== Received: by 10.224.60.18 with SMTP id n18mr19993937qah.36.1353532589388; Wed, 21 Nov 2012 13:16:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.60.18 with SMTP id n18mr19993931qah.36.1353532589255; Wed, 21 Nov 2012 13:16:29 -0800 (PST) Received: by 10.229.105.230 with HTTP; Wed, 21 Nov 2012 13:16:29 -0800 (PST) In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63074740E9BE@mbx-01.win.nominum.com> References: <8D23D4052ABE7A4490E77B1A012B63074740E9BE@mbx-01.win.nominum.com> Date: Wed, 21 Nov 2012 13:16:29 -0800 Message-ID: From: Andre Kostur To: "dhcwg@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnfpzegzCUI3Vw9dAZbEM3i9i9IdYTgZbd4JR6CfaQHWYNjgEAVIye29PF0NLVI+kQcG32nPVWUcXlMlZYZbrUcwpu9H/Zo2ufdMQXyd7eTpYdfTj9nwdrAr1QCkA8dulwR1Y3r6jTc7Rmk+J5oTFzGDcI4Ig== Subject: Re: [dhcwg] Call for adoption: draft-kostur-dhc-loadbv6 X-BeenThere: dhcwg@ietf.org 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, 21 Nov 2012 21:16:31 -0000 I'm the author... we should take on this work. On Wed, Nov 21, 2012 at 12:53 PM, Ted Lemon wrote: > Andre has asked if the working group would be willing to adopt his load b= alancing draft as a working group work item. There's already been some di= scussion on the mailing list, but we haven't formally taken on the work. = The draft is here: http://tools.ietf.org/html/draft-kostur-dhc-loadbv6-03 > > If you think the dhc working group should take on this work, please reply= to this message and say so. If you think we should not take on this work= , please reply to this message and say so. If you have comments on the dr= aft, please discuss on the mailing list. > > We will evaluate consensus on or after December 5. -- Andre Kostur From Ted.Lemon@nominum.com Thu Nov 22 04:53: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 7D43621F87DE for ; Thu, 22 Nov 2012 04:53:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.573 X-Spam-Level: X-Spam-Status: No, score=-106.573 tagged_above=-999 required=5 tests=[AWL=0.026, 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 xGNyicYSwiTt for ; Thu, 22 Nov 2012 04:53:14 -0800 (PST) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id D9D0D21F87DC for ; Thu, 22 Nov 2012 04:53:13 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKUK4gOfRIk2llkNVDcYiPym7pqMvrdZlm@postini.com; Thu, 22 Nov 2012 04:53:13 PST 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 E63E11B806B for ; Thu, 22 Nov 2012 04:53:12 -0800 (PST) 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 DDFB3190043 for ; Thu, 22 Nov 2012 04:53:12 -0800 (PST) (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.0318.004; Thu, 22 Nov 2012 04:53:12 -0800 From: Ted Lemon To: "dhcwg@ietf.org WG" Thread-Topic: WGLC: draft-ietf-dhc-triggered-reconfigure-01 Thread-Index: AQHNyLBUWbTab3EEAU6hzuU4icTAzg== Date: Thu, 22 Nov 2012 12:53:12 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63074740F186@mbx-01.win.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: <06B195869D33274C8D18F19A5EFADD6E@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dhcwg] WGLC: draft-ietf-dhc-triggered-reconfigure-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, 22 Nov 2012 12:53:14 -0000 The authors have requested a working group last call on the triggered-recon= figure draft. This draft allows the relay agent to communicate to the DHC= P server that configuration information provided by the relay agent has cha= nged. The DHCP server may then, if so configured, send a Reconfigure mess= age to the client. Please read the document and send any comments and suggestions to the maili= ng list. If you think this work should proceed, please reply to this mess= age and say so. If you think it should not proceed, please also reply and= say so. We will evaluate consensus on December 6. From ghalwasi@cisco.com Thu Nov 22 04:58: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 05EE221F88FC for ; Thu, 22 Nov 2012 04:58:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cZD1RmLumNK9 for ; Thu, 22 Nov 2012 04:58:54 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 2F1A921F87DC for ; Thu, 22 Nov 2012 04:58:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1141; q=dns/txt; s=iport; t=1353589134; x=1354798734; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=m6sRvuxI7j6HUAynmUb41ZR5IdI3K9mnX6JAUhCah3U=; b=PEnonwSrWD2DKptxUSjDpN2uXmIXT70DXJz0UhZb6I3t8/CM2FF6Diqs Wr0xGdw01iHao2S6zU/yXXpUYuMR/y+N5wsgF7vQpG9bNEMelMyKnSZsD Gi+syjsIX2PVENvrblz9WRBoDp/2Nzf7wvJ43dioEOyIgRdWDtwecTJM7 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFADUhrlCtJXG+/2dsb2JhbABEwh0Wc4IeAQEBBAEBATc0FwQCAQgRBAEBCxQJBycLFAkIAgQBEgiIBQy/fQSMN4NwYQOmQ4Jvgh0 X-IronPort-AV: E=McAfee;i="5400,1158,6903"; a="145250501" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-4.cisco.com with ESMTP; 22 Nov 2012 12:58:53 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id qAMCwr9P024951 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 22 Nov 2012 12:58:53 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.38]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0318.001; Thu, 22 Nov 2012 06:58:53 -0600 From: "Gaurav Halwasia (ghalwasi)" To: Ted Lemon , "dhcwg@ietf.org WG" Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-triggered-reconfigure-01 Thread-Index: AQHNyLBUWbTab3EEAU6hzuU4icTAzpf10Ldw Date: Thu, 22 Nov 2012 12:58:52 +0000 Message-ID: <90903C21C73202418A48BFBE80AEE5EB1BDEAF47@xmb-aln-x06.cisco.com> References: <8D23D4052ABE7A4490E77B1A012B63074740F186@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63074740F186@mbx-01.win.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.80.77] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-triggered-reconfigure-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, 22 Nov 2012 12:58:55 -0000 I have read and reviewed this draft and I support this work and would like = to see this document to move forward. Thanks, Gaurav -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= ed Lemon Sent: Thursday, November 22, 2012 6:23 PM To: dhcwg@ietf.org WG Subject: [dhcwg] WGLC: draft-ietf-dhc-triggered-reconfigure-01 The authors have requested a working group last call on the triggered-recon= figure draft. This draft allows the relay agent to communicate to the DHC= P server that configuration information provided by the relay agent has cha= nged. The DHCP server may then, if so configured, send a Reconfigure mess= age to the client. Please read the document and send any comments and suggestions to the maili= ng list. If you think this work should proceed, please reply to this mess= age and say so. If you think it should not proceed, please also reply and= say so. We will evaluate consensus on December 6. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From budmillwood@gmail.com Fri Nov 23 06:09: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 78BE621F85B8 for ; Fri, 23 Nov 2012 06:09:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 BLmqQ5y7aOwC for ; Fri, 23 Nov 2012 06:09:19 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3232E21F85CE for ; Fri, 23 Nov 2012 06:09:19 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so6496078ieb.31 for ; Fri, 23 Nov 2012 06:09:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=f8asqBmmkfXAIOh4UALUB0eHUT7QBizukli8FR97zUU=; b=q5u4+gCd2gY6PY17p1GyqSd8AIkNlGw0gCMuVnjzeLGdf37HqSmTaPAUBSL//28ecw Ff27pw/RVjG8pAYmkMBu98R6c4QkzqzMVxtjxz7WW7pUrobDycy+Q7sggEDsqry302eB E0hS9i0J5IIEaJzbSaZQc7Anze2uHJ1TWu6asU+xcD3LMgFJU0zBIyt+Hu9chvPG3yh7 TGWnEPr1qTNNAZS9llVFo7WlAWyp4Hmpu/asj0eWgM9G7tEPoHr2bj4uMkcX8cd26Ah0 3fpTzQsxLp4S1aUuuX2y46/liWeobPXRN0/qe52MdK4p/Fn7zLI1mOgOy7kTILfy54eA uf6w== MIME-Version: 1.0 Received: by 10.50.37.133 with SMTP id y5mr3633644igj.8.1353679758747; Fri, 23 Nov 2012 06:09:18 -0800 (PST) Sender: budmillwood@gmail.com Received: by 10.64.8.236 with HTTP; Fri, 23 Nov 2012 06:09:18 -0800 (PST) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E9751E53D@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E947B0E73@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E95C9F87B@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E9751E53D@PUEXCB1B.nanterre.francetelecom.fr> Date: Fri, 23 Nov 2012 15:09:18 +0100 X-Google-Sender-Auth: IFSE-nE5E3csWp9zKwiPJ9KGkjg Message-ID: From: Bud Millwood To: mohamed.boucadair@orange.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "" , Andre Kostur , "Bernie Volz \(volz\)" , Ted Lemon Subject: Re: [dhcwg] IP address vs. FQDN discussion X-BeenThere: dhcwg@ietf.org 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, 23 Nov 2012 14:09:23 -0000 >>Space in DHCPv4 packets is limited. Encoding an IP address as text is >>a huge waste of valuable packet space for that protocol. > > Med: I don't see this as an issue as fqdn can be conveyed also in a dhcpv= 4 option. Sure, you can convey FQDN, but in many cases you can also convey a binary IP address. If you're short on space, you prefer binary representation of an IP address over fqdn. We're counting bytes in DHCPv4 packets, and the difference between 4 bytes versus even 5 or 6 bytes can mean a lot. To be clear, my concern is specifically about DHCPv4. Your proposal solves a sticky problem, but it comes at a cost and I'm not sure that cost is acceptable for DHCPv4. >> >>Also, proposing that multiple names be separated with whitespace is >>equivalent to either a) introducing a new encoding for sequences or b) >>having the option value treated as opaque date. If it's the latter, we >>lose the ability to verify that the payload is properly formatted. > > Med: in -02, we are using length-encoded strings to pack multiple options= when needed. Sounds great, I'm all for it. >>Some options use a type specifier, 0 or 1, to denote ip address or dns >>name. Is there any reason to not use that? > > Med: dhw wg is not in favor of that design; please refer to http://tools.= ietf.org/html/draft-ietf-dhc-option-guidelines-08#section-7. I was tempted to originally write "Is there any reason not to use that, besides the fact that we all hate it?" Although we all hate conditional typing for DHCPv4 options, I'm concerned that your solution will fail to achieve its desired goal in DHCPv4, namely to actually convey the option. When space runs out, there's not much to do except leave out some options. To the guys I've CC:ed: Do you support this for DHCPv4? If so, is my concern unfounded? - Bud >> >>- Bud >> >>On Thu, Nov 15, 2012 at 4:04 PM, wrote: >>> Dear Erik, >>> >>> Thanks for reading the draft and also for supporting this proposal. >>> >>> For information, I have submitted an updated version of the >>draft which is available at: >>> >>> >>http://tools.ietf.org/html/draft-boucadair-dhc-address-name-encoding-02 >>> >>> Comments from WG are more than welcome. >>> >>> Cheers, >>> Med >>> >>>>-----Message d'origine----- >>>>De : Erik Kline [mailto:ek@google.com] >>>>Envoy=E9 : jeudi 15 novembre 2012 04:24 >>>>=C0 : BOUCADAIR Mohamed OLNC/OLN >>>>Cc : >>>>Objet : Re: [dhcwg] IP address vs. FQDN discussion >>>> >>>>After a very cursory reading, I would say largely +1. I'm in favour >>>>of something like "a UTF-8 string intended to passed to a >>higher layer >>>>address resolution mechanism, a la getaddrinfo(), et cetera". >>>> >>>>On 8 November 2012 07:30, wrote: >>>>> Dear all, >>>>> >>>>> As this question is repeatedly raised, including in the >>>>ongoing dhc meeting, >>>>> we have edited a draft which proposes an approach which >>>>conciliates both >>>>> modes: It defines a name option encoded as UTF-8 string >>>>which can be a >>>>> domain name, IPv4 address literals, etc. The draft is available at: >>>>> >>>>> >>>>http://tools.ietf.org/html/draft-boucadair-dhc-address-name-e >>ncoding-01 >>>>> >>>>> Comments are welcome. >>>>> >>>>> Cheers, >>>>> Med >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 budmillwood@gmail.com Fri Nov 23 06:13:41 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 2120021F853C for ; Fri, 23 Nov 2012 06:13:41 -0800 (PST) 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 TAkymy60yF+q for ; Fri, 23 Nov 2012 06:13:40 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8322C21F8539 for ; Fri, 23 Nov 2012 06:13:40 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so6502709ieb.31 for ; Fri, 23 Nov 2012 06:13:40 -0800 (PST) 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=j+qcc5AxbBOW69AmZMVKlgLJJR9qnDqCOjA5YxJFST0=; b=hq1Eo0HxukK+Fw5wLMgMU4SGn94tzR7lxj/w/CWbFMLFTeVo/+vi3fuROKhjimT2z3 2oP6j9SYpVrMyjL7Vm5AhfXeEI95nAlwFI1BrT6lLGet/v/p++ObAcBYA4Tk8HgvWvM3 Wk2qNBiugCR8uUbqAp8SJ2a2rY/zQkNkv/Zc2o7JqUILyjRwU5LaW2A0EHwe8brbXVWB UyutKkDNQVNll43uVVE0JZzAbwxBxEOPcnlSLuh0PZObHZr4xdTiKceIwt5wjEWOpAwx LuN+Bi2/7j4bYT8YhZlMQS5j3ojneZxIiH8iAGGGlgWW3p5IGgFPb9uRWo1TAk/L16sV E/Zw== MIME-Version: 1.0 Received: by 10.50.37.133 with SMTP id y5mr3645599igj.8.1353680020188; Fri, 23 Nov 2012 06:13:40 -0800 (PST) Received: by 10.64.8.236 with HTTP; Fri, 23 Nov 2012 06:13:40 -0800 (PST) In-Reply-To: References: <8D23D4052ABE7A4490E77B1A012B63074740E9BE@mbx-01.win.nominum.com> Date: Fri, 23 Nov 2012 15:13:40 +0100 Message-ID: From: Bud Millwood To: Andre Kostur Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Call for adoption: draft-kostur-dhc-loadbv6 X-BeenThere: dhcwg@ietf.org 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, 23 Nov 2012 14:13:41 -0000 I'm for it. On Wed, Nov 21, 2012 at 10:16 PM, Andre Kostur wrot= e: > I'm the author... we should take on this work. > > On Wed, Nov 21, 2012 at 12:53 PM, Ted Lemon wrote= : >> Andre has asked if the working group would be willing to adopt his load = balancing draft as a working group work item. There's already been some d= iscussion on the mailing list, but we haven't formally taken on the work. = The draft is here: http://tools.ietf.org/html/draft-kostur-dhc-loadbv6-03 >> >> If you think the dhc working group should take on this work, please repl= y to this message and say so. If you think we should not take on this wor= k, please reply to this message and say so. If you have comments on the d= raft, please discuss on the mailing list. >> >> We will evaluate consensus on or after December 5. > > -- > Andre Kostur > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From Ted.Lemon@nominum.com Fri Nov 23 08:28: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 102A321F8533 for ; Fri, 23 Nov 2012 08:28:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.576 X-Spam-Level: X-Spam-Status: No, score=-106.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 TkTrmj9YA47z for ; Fri, 23 Nov 2012 08:28:44 -0800 (PST) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6B721F844B for ; Fri, 23 Nov 2012 08:28:44 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKUK+kO/uedfB5JIxDpgvf2lhjbcp6m9Js@postini.com; Fri, 23 Nov 2012 08:28:44 PST 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 4E2621B81A2 for ; Fri, 23 Nov 2012 08:28:43 -0800 (PST) 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 3DD2B190043; Fri, 23 Nov 2012 08:28:43 -0800 (PST) (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.0318.004; Fri, 23 Nov 2012 08:28:37 -0800 From: Ted Lemon To: Bud Millwood Thread-Topic: [dhcwg] IP address vs. FQDN discussion Thread-Index: Ac29xfcgXk0oSmncRrej4Wdd4AHprgFXckYAABhv9YAAQkoKgAB3S1WAANbWQAAABN2WgA== Date: Fri, 23 Nov 2012 16:28:36 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630747410569@mbx-01.win.nominum.com> References: <94C682931C08B048B7A8645303FDC9F36E947B0E73@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E95C9F87B@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E9751E53D@PUEXCB1B.nanterre.francetelecom.fr> 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: <5242098A2D01F84C820E42DADEAB6691@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "Bernie Volz \(volz\)" , Andre Kostur Subject: Re: [dhcwg] IP address vs. FQDN discussion X-BeenThere: dhcwg@ietf.org 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, 23 Nov 2012 16:28:45 -0000 On Nov 23, 2012, at 9:09 AM, Bud Millwood wrote: > To the guys I've CC:ed: Do you support this for DHCPv4? If so, is my > concern unfounded? I have never understood why people want to carry FQDNs in DHCP packets in t= he first place, and given the limited size of DHCPv4 packets, and the compa= ctness of IPv4 addresses, it really seems like a no-brainer to only support= IP addresses. In the case of IPv6 it's more debatable since IPv6 address= es are four times larger. ntp.example.com is the same number of bytes as = an IPv6 address. Plus DHCPv6 packets aren't as restricted in size. Having said that, there are always people proposing, and insisting on, FQDN= s in DHCP packets. But here is the core issue to me, and why I oppose this kind of dual encodi= ng: the encoding is subject to interpretation, and encourages bad implement= ations that have undefined failure modes. My expectation, and what I've h= eard from people who advocate sending FQDNs in text strings, is that they'l= l just hand the string to some library function that will figure out whethe= r it's an IP address or an FQDN, and do the right thing. To me this sounds like begging for problems in the future. How do we know= the library function will do the right thing? How do we know there isn't= a bug in the way the library function parses these strings? What are the= corner cases? Do IPv6 addresses need to be sent in brackets? Etc. The beauty of "this is an IPv6 address" is that there's no interpretation. = The beauty of "this is an FQDN encoded in the standard wire format" is th= e same. Put it in a text string, and you lose that. So my personal opinion on this is that authors of drafts need to choose: is= what you want an FQDN or an IP address? If you think you want an FQDN, b= ut you sort of want an IP address as well, rethink your desire for the FQDN= , since clearly it is not necessary. If you are happy to give up sending = an IP address, then you probably do need an FQDN. If you are not happy to= do that, then you probably need an IP address. You almost certainly do n= ot need both, although I'm sure you can construct a use case that shows tha= t both would be nice to have. Nice to have !=3D need. From budmillwood@gmail.com Fri Nov 23 15:49: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 A4C3421F849A for ; Fri, 23 Nov 2012 15:49:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 P3-GgTw2yvGP for ; Fri, 23 Nov 2012 15:49:57 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id E587721F8484 for ; Fri, 23 Nov 2012 15:49:56 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id j26so7344978iaf.31 for ; Fri, 23 Nov 2012 15:49:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Nlhl/1PTDToTw7kOZAEM3bWdLCCNnycsrHznGM8NoSo=; b=q1PIh7G2sKJMQFSkwvCYKIFKMli+lHYBqpEyPgN2JmGKftAxp7WUIMheuWRAE+a9so xkSW36TSvWwKfGNQPEeUF4hOhFyLq8BbJ0sa+VlTbgs3WnphOKGOFcipVLLsP5FHoPqN u6nyugaxmqjyxKKdeNwCUEgwrubJDbGS46Lcdf6UD6jyL5qHCwm+FdLqITkD9TmNeFw6 yzYF1vxjwU8wdxdgBFsQk4jHY/j+TlFJaLJMuViAiS1d4Y2eJ+9j/YTaqG09o+URqQlB PjUdSZFSWangjUeWbLwi6cmHUSoYykBqS3O9WBpV/9txsAGKSavHkJG9tQQGSUdkWAdX dMpw== MIME-Version: 1.0 Received: by 10.50.40.133 with SMTP id x5mr7608413igk.32.1353714596425; Fri, 23 Nov 2012 15:49:56 -0800 (PST) Sender: budmillwood@gmail.com Received: by 10.64.8.236 with HTTP; Fri, 23 Nov 2012 15:49:56 -0800 (PST) In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630747410569@mbx-01.win.nominum.com> References: <94C682931C08B048B7A8645303FDC9F36E947B0E73@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E95C9F87B@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E9751E53D@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630747410569@mbx-01.win.nominum.com> Date: Sat, 24 Nov 2012 00:49:56 +0100 X-Google-Sender-Auth: pdx6UcPySxLIXN665y-C8K5MMJg Message-ID: From: Bud Millwood To: Ted Lemon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "" Subject: Re: [dhcwg] IP address vs. FQDN discussion X-BeenThere: dhcwg@ietf.org 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, 23 Nov 2012 23:49:57 -0000 Thanks for responding Ted, I agree with your views. Mohamed, if you're convinced that your proposal is a good idea, you may want to re-think whether it should cover DHCPv4. - Bud > On Fri, Nov 23, 2012 at 5:28 PM, Ted Lemon wrote: > On Nov 23, 2012, at 9:09 AM, Bud Millwood wrot= e: >> To the guys I've CC:ed: Do you support this for DHCPv4? If so, is my >> concern unfounded? > > I have never understood why people want to carry FQDNs in DHCP packets in= the first place, and given the limited size of DHCPv4 packets, and the com= pactness of IPv4 addresses, it really seems like a no-brainer to only suppo= rt IP addresses. In the case of IPv6 it's more debatable since IPv6 addre= sses are four times larger. ntp.example.com is the same number of bytes a= s an IPv6 address. Plus DHCPv6 packets aren't as restricted in size. > > Having said that, there are always people proposing, and insisting on, FQ= DNs in DHCP packets. > > But here is the core issue to me, and why I oppose this kind of dual enco= ding: the encoding is subject to interpretation, and encourages bad impleme= ntations that have undefined failure modes. My expectation, and what I've= heard from people who advocate sending FQDNs in text strings, is that they= 'll just hand the string to some library function that will figure out whet= her it's an IP address or an FQDN, and do the right thing. > > To me this sounds like begging for problems in the future. How do we kn= ow the library function will do the right thing? How do we know there isn= 't a bug in the way the library function parses these strings? What are t= he corner cases? Do IPv6 addresses need to be sent in brackets? Etc. > > The beauty of "this is an IPv6 address" is that there's no interpretation= . The beauty of "this is an FQDN encoded in the standard wire format" is = the same. Put it in a text string, and you lose that. > > So my personal opinion on this is that authors of drafts need to choose: = is what you want an FQDN or an IP address? If you think you want an FQDN,= but you sort of want an IP address as well, rethink your desire for the FQ= DN, since clearly it is not necessary. If you are happy to give up sendin= g an IP address, then you probably do need an FQDN. If you are not happy = to do that, then you probably need an IP address. You almost certainly do= not need both, although I'm sure you can construct a use case that shows t= hat both would be nice to have. Nice to have !=3D need. > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From mohamed.boucadair@orange.com Mon Nov 26 04:14: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 C484521F858E for ; Mon, 26 Nov 2012 04:14:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[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 xFMM7+kKtkP9 for ; Mon, 26 Nov 2012 04:14:40 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 0080F21F8588 for ; Mon, 26 Nov 2012 04:14:39 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 1173C2DC1E0; Mon, 26 Nov 2012 13:14:39 +0100 (CET) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id CB96023806F; Mon, 26 Nov 2012 13:14:38 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Mon, 26 Nov 2012 13:14:38 +0100 From: To: Bud Millwood Date: Mon, 26 Nov 2012 13:14:37 +0100 Thread-Topic: [dhcwg] IP address vs. FQDN discussion Thread-Index: Ac3JhCNo8TpeTRgPRLiZKFX7kNNypQCSrPbQ Message-ID: <94C682931C08B048B7A8645303FDC9F36E987229EE@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E947B0E73@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E95C9F87B@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E9751E53D@PUEXCB1B.nanterre.francetelecom.fr> 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.11.26.100617 Cc: "" , Andre Kostur , "Bernie Volz \(volz\)" , Ted Lemon Subject: Re: [dhcwg] IP address vs. FQDN discussion X-BeenThere: dhcwg@ietf.org 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, 26 Nov 2012 12:14:40 -0000 Dear Bud, Please see inline.=20 Cheers, Med=20 >-----Message d'origine----- >De : budmillwood@gmail.com [mailto:budmillwood@gmail.com] De=20 >la part de Bud Millwood >Envoy=E9 : vendredi 23 novembre 2012 15:09 >=C0 : BOUCADAIR Mohamed OLNC/OLN >Cc : ; Bernie Volz (volz); Ted Lemon; Andre Kostur >Objet : Re: [dhcwg] IP address vs. FQDN discussion > >>>Space in DHCPv4 packets is limited. Encoding an IP address as text is >>>a huge waste of valuable packet space for that protocol. >> >> Med: I don't see this as an issue as fqdn can be conveyed=20 >also in a dhcpv4 option. > >Sure, you can convey FQDN, but in many cases you can also convey a >binary IP address. If you're short on space, you prefer binary >representation of an IP address over fqdn. We're counting bytes in >DHCPv4 packets, and the difference between 4 bytes versus even 5 or 6 >bytes can mean a lot. > >To be clear, my concern is specifically about DHCPv4. Your proposal >solves a sticky problem, but it comes at a cost and I'm not sure that >cost is acceptable for DHCPv4. Med: I see your concerns. The recommendation can focus on DHCPv6 options as= these are likely to be the majority of options to be defined by the IETF i= n the future. > >>> >>>Also, proposing that multiple names be separated with whitespace is >>>equivalent to either a) introducing a new encoding for=20 >sequences or b) >>>having the option value treated as opaque date. If it's the=20 >latter, we >>>lose the ability to verify that the payload is properly formatted. >> >> Med: in -02, we are using length-encoded strings to pack=20 >multiple options when needed. > >Sounds great, I'm all for it. Med: Ok, thanks. > >>>Some options use a type specifier, 0 or 1, to denote ip=20 >address or dns >>>name. Is there any reason to not use that? >> >> Med: dhw wg is not in favor of that design; please refer to=20 >http://tools.ietf.org/html/draft-ietf-dhc-option-guidelines-08# >section-7. > >I was tempted to originally write "Is there any reason not to use >that, besides the fact that we all hate it?" Although we all hate >conditional typing for DHCPv4 options, I'm concerned that your >solution will fail to achieve its desired goal in DHCPv4, namely to >actually convey the option. When space runs out, there's not much to >do except leave out some options. > >To the guys I've CC:ed: Do you support this for DHCPv4? If so, is my >concern unfounded? > >- Bud > >>> >>>- Bud >>> >>>On Thu, Nov 15, 2012 at 4:04 PM, =20 > wrote: >>>> Dear Erik, >>>> >>>> Thanks for reading the draft and also for supporting this proposal. >>>> >>>> For information, I have submitted an updated version of the >>>draft which is available at: >>>> >>>> >>>http://tools.ietf.org/html/draft-boucadair-dhc-address-name-e >ncoding-02 >>>> >>>> Comments from WG are more than welcome. >>>> >>>> Cheers, >>>> Med >>>> >>>>>-----Message d'origine----- >>>>>De : Erik Kline [mailto:ek@google.com] >>>>>Envoy=E9 : jeudi 15 novembre 2012 04:24 >>>>>=C0 : BOUCADAIR Mohamed OLNC/OLN >>>>>Cc : >>>>>Objet : Re: [dhcwg] IP address vs. FQDN discussion >>>>> >>>>>After a very cursory reading, I would say largely +1. I'm=20 >in favour >>>>>of something like "a UTF-8 string intended to passed to a >>>higher layer >>>>>address resolution mechanism, a la getaddrinfo(), et cetera". >>>>> >>>>>On 8 November 2012 07:30, wrote: >>>>>> Dear all, >>>>>> >>>>>> As this question is repeatedly raised, including in the >>>>>ongoing dhc meeting, >>>>>> we have edited a draft which proposes an approach which >>>>>conciliates both >>>>>> modes: It defines a name option encoded as UTF-8 string >>>>>which can be a >>>>>> domain name, IPv4 address literals, etc. The draft is=20 >available at: >>>>>> >>>>>> >>>>>http://tools.ietf.org/html/draft-boucadair-dhc-address-name-e >>>ncoding-01 >>>>>> >>>>>> Comments are welcome. >>>>>> >>>>>> Cheers, >>>>>> Med >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 mohamed.boucadair@orange.com Mon Nov 26 04:38:13 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E813F21F8521 for ; Mon, 26 Nov 2012 04:38:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[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 J95hdZQ+KLdL for ; Mon, 26 Nov 2012 04:38:13 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id DE3B821F851B for ; Mon, 26 Nov 2012 04:38:12 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 1CF4226428E; Mon, 26 Nov 2012 13:38:12 +0100 (CET) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id F2BC94C017; Mon, 26 Nov 2012 13:38:11 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Mon, 26 Nov 2012 13:38:11 +0100 From: To: Ted Lemon , Bud Millwood Date: Mon, 26 Nov 2012 13:38:10 +0100 Thread-Topic: [dhcwg] IP address vs. FQDN discussion Thread-Index: Ac29xfcgXk0oSmncRrej4Wdd4AHprgFXckYAABhv9YAAQkoKgAB3S1WAANbWQAAABN2WgAB9PwEA Message-ID: <94C682931C08B048B7A8645303FDC9F36E987229FD@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E947B0E73@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E95C9F87B@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E9751E53D@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630747410569@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630747410569@mbx-01.win.nominum.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.11.26.54526 Cc: "" , "Bernie Volz \(volz\)" , Andre Kostur Subject: Re: [dhcwg] IP address vs. FQDN discussion X-BeenThere: dhcwg@ietf.org 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, 26 Nov 2012 12:38:14 -0000 Hi Ted, Please see inline.=20 Cheers, Med=20 >-----Message d'origine----- >De : Ted Lemon [mailto:Ted.Lemon@nominum.com]=20 >Envoy=E9 : vendredi 23 novembre 2012 17:29 >=C0 : Bud Millwood >Cc : BOUCADAIR Mohamed OLNC/OLN; ; Bernie Volz=20 >(volz); Andre Kostur >Objet : Re: [dhcwg] IP address vs. FQDN discussion > >On Nov 23, 2012, at 9:09 AM, Bud Millwood=20 > wrote: >> To the guys I've CC:ed: Do you support this for DHCPv4? If so, is my >> concern unfounded? > >I have never understood why people want to carry FQDNs in DHCP=20 >packets in the first place, and given the limited size of=20 >DHCPv4 packets, and the compactness of IPv4 addresses, it=20 >really seems like a no-brainer to only support IP addresses. =20 >In the case of IPv6 it's more debatable since IPv6 addresses=20 >are four times larger. ntp.example.com is the same number of=20 >bytes as an IPv6 address. Plus DHCPv6 packets aren't as=20 >restricted in size. > >Having said that, there are always people proposing, and=20 >insisting on, FQDNs in DHCP packets. > >But here is the core issue to me, and why I oppose this kind=20 >of dual encoding: the encoding is subject to interpretation,=20 >and encourages bad implementations that have undefined failure=20 >modes. My expectation, and what I've heard from people who=20 >advocate sending FQDNs in text strings, is that they'll just=20 >hand the string to some library function that will figure out=20 >whether it's an IP address or an FQDN, and do the right thing. > Med: Yes, that's the main point.=20 >To me this sounds like begging for problems in the future. =20 >How do we know the library function will do the right thing? =20 >How do we know there isn't a bug in the way the library=20 Med: We know the behaviour of current name resolution libraries, so we can = define a safe validation procedure for these libraries. Should we speculate= on the evolution of these name resolution libraries? IMO, I don't think so= . Note, DNS names can be returned in dhcp options but dns is not the only a= vailable name resolution service... >function parses these strings? What are the corner cases? =20 >Do IPv6 addresses need to be sent in brackets? Etc. Med: This is part of the validation procedure. The draft can work better th= is part once the idea of dual encoding is understood. > >The beauty of "this is an IPv6 address" is that there's no=20 >interpretation. The beauty of "this is an FQDN encoded in=20 >the standard wire format" is the same. Put it in a text=20 >string, and you lose that. > >So my personal opinion on this is that authors of drafts need=20 >to choose: Med: We can make a choice/decision but it may not be appropriate for all de= ployments. This is why I do still think it does not make sense to dictate w= hich option a provider need to support. There are arguments in favour of an= IP address and other arguments in favour of FQDN. This is what this draft = is trying to achieve in this section: http://tools.ietf.org/html/draft-bouc= adair-dhc-address-name-encoding-02#section-2. is what you want an FQDN or an IP address? If you=20 >think you want an FQDN, but you sort of want an IP address as=20 >well, rethink your desire for the FQDN, since clearly it is=20 >not necessary. If you are happy to give up sending an IP=20 >address, then you probably do need an FQDN. If you are not=20 >happy to do that, then you probably need an IP address.=20 Med: This is exactly what this draft is for: choose what you want to convey= in the option: an ip address or a fqdn. You=20 >almost certainly do not need both, Med: Agree. although I'm sure you can=20 >construct a use case that shows that both would be nice to=20 >have. Nice to have !=3D need. Med: This draft is not advocating for defining two options but: * it argues both encoding may be needed in different deployment contexts.=20 * it proposes one single option to meet both IP/FQDN needs. > >= From Ted.Lemon@nominum.com Mon Nov 26 05:46: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 9FA1B21F8460 for ; Mon, 26 Nov 2012 05:46:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BfHni6594qaC for ; Mon, 26 Nov 2012 05:46:14 -0800 (PST) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id E096921F845F for ; Mon, 26 Nov 2012 05:46:13 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKULNypUqdYPMY0MLCrx6d+hfobOx2Qs6x@postini.com; Mon, 26 Nov 2012 05:46:13 PST 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 C39B91B8075 for ; Mon, 26 Nov 2012 05:46:12 -0800 (PST) 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 B938D190043; Mon, 26 Nov 2012 05:46:12 -0800 (PST) (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.0318.004; Mon, 26 Nov 2012 05:46:13 -0800 From: Ted Lemon To: "mohamed.boucadair@orange.com" Thread-Topic: [dhcwg] IP address vs. FQDN discussion Thread-Index: Ac29xfcgXk0oSmncRrej4Wdd4AHprgFXckYAABhv9YAAQkoKgAB3S1WAANbWQAAABN2WgAB9PwEAABP0ZAA= Date: Mon, 26 Nov 2012 13:46:12 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630747413582@mbx-01.win.nominum.com> References: <94C682931C08B048B7A8645303FDC9F36E947B0E73@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E95C9F87B@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E9751E53D@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630747410569@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36E987229FD@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E987229FD@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: <7162A23AB272894095C5932F83B2C831@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , Andre Kostur , "Bernie Volz \(volz\)" , Bud Millwood Subject: Re: [dhcwg] IP address vs. FQDN discussion X-BeenThere: dhcwg@ietf.org 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, 26 Nov 2012 13:46:14 -0000 On Nov 26, 2012, at 7:38 AM, mohamed.boucadair@orange.com wrote: >> To me this sounds like begging for problems in the future. =20 >> How do we know the library function will do the right thing? =20 >> How do we know there isn't a bug in the way the library=20 >=20 > Med: We know the behaviour of current name resolution libraries, so we ca= n define a safe validation procedure for these libraries. Should we specula= te on the evolution of these name resolution libraries? IMO, I don't think = so. Note, DNS names can be returned in dhcp options but dns is not the only= available name resolution service... Right, this is the core of the problem. The problem is open-ended. If y= ou just send an IP address, you can put all this complexity on the server, = and because it's monolithic, there's no interoperation, and hence no intero= perability problems. Whereas if you use DHCP as a conduit between heterog= enous hosts, the server implementation has no way to anticipate what might = happen on the client. > Med: We can make a choice/decision but it may not be appropriate for all = deployments. This is why I do still think it does not make sense to dictate= which option a provider need to support. There are arguments in favour of = an IP address and other arguments in favour of FQDN. This is what this draf= t is trying to achieve in this section:http://tools.ietf.org/html/draft-bou= cadair-dhc-address-name-encoding-02#section-2. There are some good arguments here in favor of using an FQDN. If these ar= guments are sufficient to justify requiring a resolver, then you should use= an FQDN and not support an IP address. Otherwise you will have some devi= ces that support the FQDN, and some that do not, and you will run into inte= roperability problems. From kkinnear@cisco.com Mon Nov 26 07:34: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 A9A9321F85AB for ; Mon, 26 Nov 2012 07:34:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tChomDz9jW5k for ; Mon, 26 Nov 2012 07:34:26 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 2CB2521F8588 for ; Mon, 26 Nov 2012 07:34:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3189; q=dns/txt; s=iport; t=1353944066; x=1355153666; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=L0CGcXtKK14re5KtiEgF6UB1D3WTxf1OGQMtSamtiDc=; b=UAk1Yo73tISPYn0SiBNT0moX2v/jJPwUskkO5x3npaJtDrsgXHKQF1cP 4tmM5LREG5DrMdzNfhI3URQclKDnYLedRbECbs5v1E3GQTndnfOAD5Ikn iJYuU/Q8VLwWUjj98lEgJ0/sV3O7RpigDNG1WhcGVmmrZTMRKeJeEdO5v E=; X-IronPort-AV: E=McAfee;i="5400,1158,6907"; a="143226205" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-9.cisco.com with ESMTP; 26 Nov 2012 15:34:25 +0000 Received: from [161.44.65.104] ([161.44.65.104]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id qAQFYPjH020418; Mon, 26 Nov 2012 15:34:25 GMT Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Kim Kinnear In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630747410569@mbx-01.win.nominum.com> Date: Mon, 26 Nov 2012 10:34:29 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <706C6EB5-3833-46B8-B79F-B8A4340669CE@cisco.com> References: <94C682931C08B048B7A8645303FDC9F36E947B0E73@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E95C9F87B@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E9751E53D@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630747410569@mbx-01.win.nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1278) Cc: "" , Andre Kostur , Bud Millwood , "Bernie Volz \(volz\)" , Kim Kinnear Subject: Re: [dhcwg] IP address vs. FQDN discussion X-BeenThere: dhcwg@ietf.org 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, 26 Nov 2012 15:34:32 -0000 Ted,=20 Thank you for stating this so clearly. I was working up to trying to say pretty much the same thing, but you beat me to it, and stated it better as well. I would add that, having seen real world environments grind to a halt because they used FQDN's for configuration and DNS servers were unavailable, I cannot see how anyone could want to use an FQDN when an IP address would do. If you absolutely *have* to have an FQDN, then build that into the draft as the only approach. If you don't *have* to have an FQDN, then by all means use an IP address and make that the only approach. Regards -- Kim On Nov 23, 2012, at 11:28 AM, Ted Lemon wrote: > On Nov 23, 2012, at 9:09 AM, Bud Millwood = wrote: >> To the guys I've CC:ed: Do you support this for DHCPv4? If so, is my >> concern unfounded? >=20 > I have never understood why people want to carry FQDNs in DHCP packets = in the first place, and given the limited size of DHCPv4 packets, and = the compactness of IPv4 addresses, it really seems like a no-brainer to = only support IP addresses. In the case of IPv6 it's more debatable = since IPv6 addresses are four times larger. ntp.example.com is the = same number of bytes as an IPv6 address. Plus DHCPv6 packets aren't as = restricted in size. >=20 > Having said that, there are always people proposing, and insisting on, = FQDNs in DHCP packets. >=20 > But here is the core issue to me, and why I oppose this kind of dual = encoding: the encoding is subject to interpretation, and encourages bad = implementations that have undefined failure modes. My expectation, and = what I've heard from people who advocate sending FQDNs in text strings, = is that they'll just hand the string to some library function that will = figure out whether it's an IP address or an FQDN, and do the right = thing. >=20 > To me this sounds like begging for problems in the future. How do we = know the library function will do the right thing? How do we know = there isn't a bug in the way the library function parses these strings? = What are the corner cases? Do IPv6 addresses need to be sent in = brackets? Etc. >=20 > The beauty of "this is an IPv6 address" is that there's no = interpretation. The beauty of "this is an FQDN encoded in the standard = wire format" is the same. Put it in a text string, and you lose that. >=20 > So my personal opinion on this is that authors of drafts need to = choose: is what you want an FQDN or an IP address? If you think you = want an FQDN, but you sort of want an IP address as well, rethink your = desire for the FQDN, since clearly it is not necessary. If you are = happy to give up sending an IP address, then you probably do need an = FQDN. If you are not happy to do that, then you probably need an IP = address. You almost certainly do not need both, although I'm sure you = can construct a use case that shows that both would be nice to have. = Nice to have !=3D need. >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From stenc@s-carlsen.dk Mon Nov 26 07:38:18 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 5436D21F85AF for ; Mon, 26 Nov 2012 07:38:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.589 X-Spam-Level: X-Spam-Status: No, score=-1.589 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DK=1.009, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08VXjzIuCHk0 for ; Mon, 26 Nov 2012 07:38:17 -0800 (PST) Received: from mail2.s-carlsen.dk (0134100024.0.fullrate.dk [90.185.128.210]) by ietfa.amsl.com (Postfix) with ESMTP id 3742C21F8538 for ; Mon, 26 Nov 2012 07:38:17 -0800 (PST) Received: from silver3airport.s-carlsen.dk (silver3AirPort.s-carlsen.dk [192.168.16.117]) by mail2.s-carlsen.dk (Postfix) with ESMTPA id 8F3E6224 for ; Mon, 26 Nov 2012 16:38:12 +0100 (CET) Message-ID: <50B38CE3.5060806@s-carlsen.dk> Date: Mon, 26 Nov 2012 16:38:11 +0100 From: Sten Carlsen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: dhcwg@ietf.org References: <94C682931C08B048B7A8645303FDC9F36E947B0E73@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E95C9F87B@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E9751E53D@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630747410569@mbx-01.win.nominum.com> <706C6EB5-3833-46B8-B79F-B8A4340669CE@cisco.com> In-Reply-To: <706C6EB5-3833-46B8-B79F-B8A4340669CE@cisco.com> X-Enigmail-Version: 1.4.6 Content-Type: multipart/alternative; boundary="------------080106080001030902000206" Subject: Re: [dhcwg] IP address vs. FQDN discussion X-BeenThere: dhcwg@ietf.org 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, 26 Nov 2012 15:38:18 -0000 This is a multi-part message in MIME format. --------------080106080001030902000206 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Just a thought, load balancers and other appliances that may have more than one IP, would they have any relevance for this? If not, then fine, forget this. On 26/11/12 16:34, Kim Kinnear wrote: > Ted, > > Thank you for stating this so clearly. I was working up to > trying to say pretty much the same thing, but you beat me to it, > and stated it better as well. > > I would add that, having seen real world environments grind to a > halt because they used FQDN's for configuration and DNS servers > were unavailable, I cannot see how anyone could want to use an > FQDN when an IP address would do. > > If you absolutely *have* to have an FQDN, then build that into > the draft as the only approach. If you don't *have* to have an > FQDN, then by all means use an IP address and make that the only > approach. > > Regards -- Kim > > On Nov 23, 2012, at 11:28 AM, Ted Lemon wrote: > >> On Nov 23, 2012, at 9:09 AM, Bud Millwood wrote: >>> To the guys I've CC:ed: Do you support this for DHCPv4? If so, is my >>> concern unfounded? >> I have never understood why people want to carry FQDNs in DHCP packets in the first place, and given the limited size of DHCPv4 packets, and the compactness of IPv4 addresses, it really seems like a no-brainer to only support IP addresses. In the case of IPv6 it's more debatable since IPv6 addresses are four times larger. ntp.example.com is the same number of bytes as an IPv6 address. Plus DHCPv6 packets aren't as restricted in size. >> >> Having said that, there are always people proposing, and insisting on, FQDNs in DHCP packets. >> >> But here is the core issue to me, and why I oppose this kind of dual encoding: the encoding is subject to interpretation, and encourages bad implementations that have undefined failure modes. My expectation, and what I've heard from people who advocate sending FQDNs in text strings, is that they'll just hand the string to some library function that will figure out whether it's an IP address or an FQDN, and do the right thing. >> >> To me this sounds like begging for problems in the future. How do we know the library function will do the right thing? How do we know there isn't a bug in the way the library function parses these strings? What are the corner cases? Do IPv6 addresses need to be sent in brackets? Etc. >> >> The beauty of "this is an IPv6 address" is that there's no interpretation. The beauty of "this is an FQDN encoded in the standard wire format" is the same. Put it in a text string, and you lose that. >> >> So my personal opinion on this is that authors of drafts need to choose: is what you want an FQDN or an IP address? If you think you want an FQDN, but you sort of want an IP address as well, rethink your desire for the FQDN, since clearly it is not necessary. If you are happy to give up sending an IP address, then you probably do need an FQDN. If you are not happy to do that, then you probably need an IP address. You almost certainly do not need both, although I'm sure you can construct a use case that shows that both would be nice to have. Nice to have != need. >> >> _______________________________________________ >> 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 -- Best regards Sten Carlsen No improvements come from shouting: "MALE BOVINE MANURE!!!" --------------080106080001030902000206 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Just a thought, load balancers and other appliances that may have more than one IP, would they have any relevance for this? If not, then fine, forget this.

On 26/11/12 16:34, Kim Kinnear wrote:
Ted, 

Thank you for stating this so clearly.  I was working up to
trying to say pretty much the same thing, but you beat me to it,
and stated it better as well.

I would add that, having seen real world environments grind to a
halt because they used FQDN's for configuration and DNS servers
were unavailable, I cannot see how anyone could want to use an
FQDN when an IP address would do.

If you absolutely *have* to have an FQDN, then build that into
the draft as the only approach.  If you don't *have* to have an
FQDN, then by all means use an IP address and make that the only
approach.

Regards -- Kim

On Nov 23, 2012, at 11:28 AM, Ted Lemon wrote:


On Nov 23, 2012, at 9:09 AM, Bud Millwood <budm@weird-solutions.com> wrote:

To the guys I've CC:ed: Do you support this for DHCPv4? If so, is my
concern unfounded?

I have never understood why people want to carry FQDNs in DHCP packets in the first place, and given the limited size of DHCPv4 packets, and the compactness of IPv4 addresses, it really seems like a no-brainer to only support IP addresses.   In the case of IPv6 it's more debatable since IPv6 addresses are four times larger.   ntp.example.com is the same number of bytes as an IPv6 address.   Plus DHCPv6 packets aren't as restricted in size.

Having said that, there are always people proposing, and insisting on, FQDNs in DHCP packets.

But here is the core issue to me, and why I oppose this kind of dual encoding: the encoding is subject to interpretation, and encourages bad implementations that have undefined failure modes.   My expectation, and what I've heard from people who advocate sending FQDNs in text strings, is that they'll just hand the string to some library function that will figure out whether it's an IP address or an FQDN, and do the right thing.

To me this sounds like begging for problems in the future.   How do we know the library function will do the right thing?   How do we know there isn't a bug in the way the library function parses these strings?   What are the corner cases?   Do IPv6 addresses need to be sent in brackets?   Etc.

The beauty of "this is an IPv6 address" is that there's no interpretation.   The beauty of "this is an FQDN encoded in the standard wire format" is the same.   Put it in a text string, and you lose that.

So my personal opinion on this is that authors of drafts need to choose: is what you want an FQDN or an IP address?   If you think you want an FQDN, but you sort of want an IP address as well, rethink your desire for the FQDN, since clearly it is not necessary.   If you are happy to give up sending an IP address, then you probably do need an FQDN.   If you are not happy to do that, then you probably need an IP address.   You almost certainly do not need both, although I'm sure you can construct a use case that shows that both would be nice to have.   Nice to have != need.

_______________________________________________
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


-- 
Best regards

Sten Carlsen

No improvements come from shouting:
       "MALE BOVINE MANURE!!!"
--------------080106080001030902000206-- From Ted.Lemon@nominum.com Mon Nov 26 07:53: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 C0D1021F85AB for ; Mon, 26 Nov 2012 07:53:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nCxc+A0LtvSS for ; Mon, 26 Nov 2012 07:53:01 -0800 (PST) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id 81D4521F85A6 for ; Mon, 26 Nov 2012 07:53:00 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKULOQXH7fFY/G7OTuzqJa7+XAXzJQs5HD@postini.com; Mon, 26 Nov 2012 07:53:00 PST 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 ADF4C1B8148 for ; Mon, 26 Nov 2012 07:52:59 -0800 (PST) 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 A41C819005C; Mon, 26 Nov 2012 07:52:59 -0800 (PST) (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.0318.004; Mon, 26 Nov 2012 07:52:59 -0800 From: Ted Lemon To: Sten Carlsen Thread-Topic: [dhcwg] IP address vs. FQDN discussion Thread-Index: Ac29xfcgXk0oSmncRrej4Wdd4AHprgFXckYAABhv9YAAQkoKgAB3S1WAANbWQAAABN2WgACU+9KAAAAhFYAAAIQGgA== Date: Mon, 26 Nov 2012 15:52:59 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307474137AE@mbx-01.win.nominum.com> References: <94C682931C08B048B7A8645303FDC9F36E947B0E73@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E95C9F87B@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E9751E53D@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630747410569@mbx-01.win.nominum.com> <706C6EB5-3833-46B8-B79F-B8A4340669CE@cisco.com> <50B38CE3.5060806@s-carlsen.dk> In-Reply-To: <50B38CE3.5060806@s-carlsen.dk> 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: <9741AB447790A04895B4EDA411BBDB72@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [dhcwg] IP address vs. FQDN discussion X-BeenThere: dhcwg@ietf.org 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, 26 Nov 2012 15:53:01 -0000 On Nov 26, 2012, at 10:38 AM, Sten Carlsen wrote: > Just a thought, load balancers and other appliances that may have more th= an one IP, would they have any relevance for this? If not, then fine, forge= t this. This is mentioned in the draft Med wrote. Of course, the DHCP server can= also do load balancing; it doesn't have to happen on the client. But any= sort of DNS strategy that does geographical load direction based on a comm= on name would fail, since the DHCP server and DHCP client are in different = locations. However, DHCP makes solving this problem easy as well=97give out different = information on different networks. All that is required is that names be = chosen for locality, rather than using the same name in all locations and h= aving the DNS server give different answers according to location. Really, all of the operational issues Med talks about in the draft _can_ be= solved with DHCP server configuration; even the double indirection problem= can be solved by simply configuring the FQDN on the DHCP server and having= the DHCP server hook it up. The DNS server administrator can change the = FQDN, and the DHCP server will quickly start using the new FQDN (assuming a= n appropriate TTL was chosen). From stenc@s-carlsen.dk Mon Nov 26 08:08: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 BD5B221F8610 for ; Mon, 26 Nov 2012 08:08:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.589 X-Spam-Level: X-Spam-Status: No, score=-1.589 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DK=1.009, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XMoOpq9jaBL5 for ; Mon, 26 Nov 2012 08:08:09 -0800 (PST) Received: from mail2.s-carlsen.dk (0134100024.0.fullrate.dk [90.185.128.210]) by ietfa.amsl.com (Postfix) with ESMTP id E535021F85AC for ; Mon, 26 Nov 2012 08:08:08 -0800 (PST) Received: from silver3airport.s-carlsen.dk (silver3AirPort.s-carlsen.dk [192.168.16.117]) by mail2.s-carlsen.dk (Postfix) with ESMTPA id 829E14BD; Mon, 26 Nov 2012 17:08:05 +0100 (CET) Message-ID: <50B393E5.2050802@s-carlsen.dk> Date: Mon, 26 Nov 2012 17:08:05 +0100 From: Sten Carlsen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Ted Lemon References: <94C682931C08B048B7A8645303FDC9F36E947B0E73@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E95C9F87B@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E9751E53D@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630747410569@mbx-01.win.nominum.com> <706C6EB5-3833-46B8-B79F-B8A4340669CE@cisco.com> <50B38CE3.5060806@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B6307474137AE@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307474137AE@mbx-01.win.nominum.com> X-Enigmail-Version: 1.4.6 Content-Type: multipart/alternative; boundary="------------010709070907070206030303" Cc: "" Subject: Re: [dhcwg] IP address vs. FQDN discussion X-BeenThere: dhcwg@ietf.org 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, 26 Nov 2012 16:08:09 -0000 This is a multi-part message in MIME format. --------------010709070907070206030303 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Ok, Thanks. On 26/11/12 16:52, Ted Lemon wrote: > On Nov 26, 2012, at 10:38 AM, Sten Carlsen wrote: >> Just a thought, load balancers and other appliances that may have more than one IP, would they have any relevance for this? If not, then fine, forget this. > This is mentioned in the draft Med wrote. Of course, the DHCP server can also do load balancing; it doesn't have to happen on the client. But any sort of DNS strategy that does geographical load direction based on a common name would fail, since the DHCP server and DHCP client are in different locations. > > However, DHCP makes solving this problem easy as well—give out different information on different networks. All that is required is that names be chosen for locality, rather than using the same name in all locations and having the DNS server give different answers according to location. > > Really, all of the operational issues Med talks about in the draft _can_ be solved with DHCP server configuration; even the double indirection problem can be solved by simply configuring the FQDN on the DHCP server and having the DHCP server hook it up. The DNS server administrator can change the FQDN, and the DHCP server will quickly start using the new FQDN (assuming an appropriate TTL was chosen). > -- Best regards Sten Carlsen No improvements come from shouting: "MALE BOVINE MANURE!!!" --------------010709070907070206030303 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Ok, Thanks.

On 26/11/12 16:52, Ted Lemon wrote:
On Nov 26, 2012, at 10:38 AM, Sten Carlsen <stenc@s-carlsen.dk> wrote:

Just a thought, load balancers and other appliances that may have more than one IP, would they have any relevance for this? If not, then fine, forget this.

This is mentioned in the draft Med wrote.    Of course, the DHCP server can also do load balancing; it doesn't have to happen on the client.   But any sort of DNS strategy that does geographical load direction based on a common name would fail, since the DHCP server and DHCP client are in different locations.

However, DHCP makes solving this problem easy as well—give out different information on different networks.   All that is required is that names be chosen for locality, rather than using the same name in all locations and having the DNS server give different answers according to location.

Really, all of the operational issues Med talks about in the draft _can_ be solved with DHCP server configuration; even the double indirection problem can be solved by simply configuring the FQDN on the DHCP server and having the DHCP server hook it up.   The DNS server administrator can change the FQDN, and the DHCP server will quickly start using the new FQDN (assuming an appropriate TTL was chosen).



-- 
Best regards

Sten Carlsen

No improvements come from shouting:
       "MALE BOVINE MANURE!!!"
--------------010709070907070206030303-- From linux@thehobsons.co.uk Mon Nov 26 10:50: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 B0AC021F8641 for ; Mon, 26 Nov 2012 10:50:29 -0800 (PST) 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 MR71CfAxGPuS for ; Mon, 26 Nov 2012 10:50:28 -0800 (PST) Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [IPv6:2001:470:1f09:baa::21]) by ietfa.amsl.com (Postfix) with ESMTP id 8C80421F8621 for ; Mon, 26 Nov 2012 10:50:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by patsy.thehobsons.co.uk (Postfix) with ESMTP id A573B10401A for ; Mon, 26 Nov 2012 18:50:17 +0000 (GMT) Received: from patsy.thehobsons.co.uk ([127.0.0.1]) by localhost (patsy.thehobsons.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KqWDdbANkAdd for ; Mon, 26 Nov 2012 18:50:17 +0000 (GMT) Received: from simon.thehobsons.co.uk (Simons-Old-MacBookPro-Virtual.thehobsons.co.uk [192.168.0.110]) by patsy.thehobsons.co.uk (Postfix) with ESMTP id 0734E29F65 for ; Mon, 26 Nov 2012 18:50:16 +0000 (GMT) Mime-Version: 1.0 Message-Id: In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307474137AE@mbx-01.win.nominum.com> References: <94C682931C08B048B7A8645303FDC9F36E947B0E73@PUEXCB1B.nanterre.franceteleco m.fr> <94C682931C08B048B7A8645303FDC9F36E95C9F87B@PUEXCB1B.nanterre.franceteleco m.fr> <94C682931C08B048B7A8645303FDC9F36E9751E53D@PUEXCB1B.nanterre.franceteleco m.fr> <8D23D4052ABE7A4490E77B1A012B630747410569@mbx-01.win.nominum.com> <706C6EB5-3833-46B8-B79F-B8A4340669CE@cisco.com> <50B38CE3.5060806@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B6307474137AE@mbx-01.win.nominum.com> Date: Mon, 26 Nov 2012 18:50:10 +0000 To: dhcwg@ietf.org From: Simon Hobson Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: Re: [dhcwg] IP address vs. FQDN discussion X-BeenThere: dhcwg@ietf.org 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, 26 Nov 2012 18:50:30 -0000 Ted Lemon wrote: >But any sort of DNS strategy that does geographical load direction >based on a common name would fail, since the DHCP server and DHCP >client are in different locations. > >However, DHCP makes solving this problem easy as well-give out >different information on different networks. All that is required >is that names be chosen for locality, rather than using the same >name in all locations and having the DNS server give different >answers according to location. That does mean duplicating config to a certain extent, and in the sort of situation where that would be used, there's a good chance that the DNS and DHCP are managed by different groups. That's not an insurmountable, or even in most cases difficult, problem to work round - but it is a situation where using FQDN would avoid a different management issue. Whether this is a significant consideration, I've leave others to argue about ! I've only worked in situation where the DHCP and DNS are managed by the same person (usually me), or at least by the same small group. -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. From Ted.Lemon@nominum.com Mon Nov 26 11:04: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 0C59321F852D for ; Mon, 26 Nov 2012 11:04:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ClZvW7+KQZEp for ; Mon, 26 Nov 2012 11:04:53 -0800 (PST) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id 3FFC221F8441 for ; Mon, 26 Nov 2012 11:04:53 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKULO9VPFbK52PIHrp3Be8RkC0NByCGCuj@postini.com; Mon, 26 Nov 2012 11:04:53 PST 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 6ABBF1B8056 for ; Mon, 26 Nov 2012 11:04:52 -0800 (PST) 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 60AF319005C; Mon, 26 Nov 2012 11:04:52 -0800 (PST) (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.0318.004; Mon, 26 Nov 2012 11:04:52 -0800 From: Ted Lemon To: Simon Hobson Thread-Topic: [dhcwg] IP address vs. FQDN discussion Thread-Index: Ac29xfcgXk0oSmncRrej4Wdd4AHprgFXckYAABhv9YAAQkoKgAB3S1WAANbWQAAABN2WgACU+9KAAAAhFYAAAIQGgAAGMHEAAACDR4A= Date: Mon, 26 Nov 2012 19:04:52 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630747413B26@mbx-01.win.nominum.com> References: <94C682931C08B048B7A8645303FDC9F36E947B0E73@PUEXCB1B.nanterre.franceteleco m.fr> <94C682931C08B048B7A8645303FDC9F36E95C9F87B@PUEXCB1B.nanterre.franceteleco m.fr> <94C682931C08B048B7A8645303FDC9F36E9751E53D@PUEXCB1B.nanterre.franceteleco m.fr> <8D23D4052ABE7A4490E77B1A012B630747410569@mbx-01.win.nominum.com> <706C6EB5-3833-46B8-B79F-B8A4340669CE@cisco.com> <50B38CE3.5060806@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B6307474137AE@mbx-01.win.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: <8F526051E349F14DBB81CD55BA182DCC@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [dhcwg] IP address vs. FQDN discussion X-BeenThere: dhcwg@ietf.org 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, 26 Nov 2012 19:04:54 -0000 On Nov 26, 2012, at 1:50 PM, Simon Hobson wrote: > That does mean duplicating config to a certain extent, and in the sort of= situation where that would be used, there's a good chance that the DNS and= DHCP are managed by different groups. That's not an insurmountable, or eve= n in most cases difficult, problem to work round - but it is a situation wh= ere using FQDN would avoid a different management issue. > Whether this is a significant consideration, I've leave others to argue a= bout ! That's not quite right. Someone always has to put the information into th= e DHCP server, and the DHCP server always has to have locality-specific con= figuration information. So the question is, should that configuration inf= ormation include different FQDNs for the same service, or should there be a= single non-local FQDN to cover that service, and then some kind of DNS inf= rastructure that gives different answers based on locality. The DNS administrator can't change the DHCP server setting, but he or she c= an trivially change the IP address to which the names refer, so this strike= s me as a non-problem=97the flexibility required in the dual-administration= situation is handled successfully, without any extra steps required. Fur= thermore, it's standards-compliant=97you are directly following the DHCP sp= ecification and the DNS specification, using functionality that's widely av= ailable and easy to configure. The FQDN solution is not standards-based: it requires special nonstandard D= NS hacks to return different answers depending on where the user is. It's= not _violating_ any standards, but we're essentially adding features to th= e DHCP _protocol_ in order to enable a nonstandard DNS _implementation_. From Stephen.Jacob@nominum.com Mon Nov 26 15:24: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 9935421F84BC for ; Mon, 26 Nov 2012 15:24:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_44=0.6, 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 pW0EwKpmKoPs for ; Mon, 26 Nov 2012 15:24:21 -0800 (PST) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id 985ED21F84B6 for ; Mon, 26 Nov 2012 15:24:19 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKULP6I7kgQoUKBy3VNhI8/0b3Ib0HjJd6@postini.com; Mon, 26 Nov 2012 15:24:21 PST Received: by shell-too.nominum.com (Postfix, from userid 11053) id C10291B818F; Mon, 26 Nov 2012 15:24:18 -0800 (PST) Date: Mon, 26 Nov 2012 15:24:18 -0800 From: Stephen Jacob To: Ted Lemon Message-ID: <20121126232418.GA1309@shell-too.nominum.com> Mail-Followup-To: Ted Lemon , Sten Carlsen , "" References: <94C682931C08B048B7A8645303FDC9F36E947B0E73@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E95C9F87B@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E9751E53D@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630747410569@mbx-01.win.nominum.com> <706C6EB5-3833-46B8-B79F-B8A4340669CE@cisco.com> <50B38CE3.5060806@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B6307474137AE@mbx-01.win.nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307474137AE@mbx-01.win.nominum.com> User-Agent: Mutt/1.4.2.2i X-URI: http://www.nominum.com/ Organization: Nominum, Inc. Cc: "" Subject: Re: [dhcwg] IP address vs. FQDN discussion X-BeenThere: dhcwg@ietf.org 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, 26 Nov 2012 23:24:22 -0000 On Mon, Nov 26, 2012 at 03:52:59PM +0000, Ted Lemon wrote: > On Nov 26, 2012, at 10:38 AM, Sten Carlsen wrote: > > Just a thought, load balancers and other appliances that may > > have more than one IP, would they have any relevance for this? > > If not, then fine, forget this. > > This is mentioned in the draft Med wrote. Of course, the DHCP > server can also do load balancing; it doesn't have to happen on > the client. But any sort of DNS strategy that does geographical > load direction based on a common name would fail, since the DHCP > server and DHCP client are in different locations. > > However, DHCP makes solving this problem easy as well?give out > different information on different networks. All that is > required is that names be chosen for locality, rather than using > the same name in all locations and having the DNS server give > different answers according to location. > > Really, all of the operational issues Med talks about in the draft > _can_ be solved with DHCP server configuration; even the double > indirection problem can be solved by simply configuring the FQDN > on the DHCP server and having the DHCP server hook it up. The > DNS server administrator can change the FQDN, and the DHCP server > will quickly start using the new FQDN (assuming an appropriate TTL > was chosen). It seems to me that there's a couple of other cases where "just use an IP address" may not always be a good solution for a given administrative domain but would be fine for others: 1. When some want to convey multiple addresses in an option that accepts a single FQDN. Perhaps this just indicates that the option should accept a list of IP addresses, but in that case you must manage the lists of IP addresses in the DHCP server (manually, or by having the server resolve names into [lists of] addresses (which sucks for the fast path of the DHCP server)). 2. When you want to convey addresses which change more frequently than (or close to as often as) the length of one's DHCP lease. 3. Sort of a special case of #2: In cases where you have DNS servers which can hand out lists of addresses that vary depending on the 'health' of the services running on the servers with those addresses. This tends to go hand-in-hand with geolocation, often under the moniker "GSLB". In this case, addresses may potentially come and go from a name with great frequency. In any/all of these cases, it may be inconvenient for someone who doesn't have the needs listed above to use FQDNs, so that seems like a case for considering providing the option of providing an address. So, while I have no love for DHCP options that may contain multiple different data formats, I do see the value in being able to do so. Regards, Stephen -- Stephen Jacob | Stephen.Jacob@nominum.com | +1 650 381 6051 Nominum, Inc. | http://www.nominum.com/ | +1 650 381 6000 From Stephen.Jacob@nominum.com Mon Nov 26 15:47: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 9607A21F8441 for ; Mon, 26 Nov 2012 15:47:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 5qoNxKRoYI7j for ; Mon, 26 Nov 2012 15:47:37 -0800 (PST) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id B156E21F843E for ; Mon, 26 Nov 2012 15:47:37 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKULP/mS534+v/NMZK1+PRyBlGA25E4Use@postini.com; Mon, 26 Nov 2012 15:47:37 PST Received: by shell-too.nominum.com (Postfix, from userid 11053) id C3BAF1B818F; Mon, 26 Nov 2012 15:47:36 -0800 (PST) Date: Mon, 26 Nov 2012 15:47:36 -0800 From: Stephen Jacob To: IETF DHC Working Group Message-ID: <20121126234736.GB1309@shell-too.nominum.com> Mail-Followup-To: IETF DHC Working Group Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i X-URI: http://www.nominum.com/ Organization: Nominum, Inc. Subject: [dhcwg] DHCPv4-over-IPv6 client-side implementations? X-BeenThere: dhcwg@ietf.org 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, 26 Nov 2012 23:47:39 -0000 Hi everyone, I know there's at least one group working on an implementation of the client side of DHCPv4-over-IPv6 (the CRA + ?), but it is not ready yet as I understand it. Do any of you know if there are any complete or mostly complete implementations which might be used for, e.g., interop testing? 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 Nov 26 19:35:20 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 5631821F8467 for ; Mon, 26 Nov 2012 19:35:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iuHNdFFcHqYF for ; Mon, 26 Nov 2012 19:35:19 -0800 (PST) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by ietfa.amsl.com (Postfix) with ESMTP id 9173F21F8481 for ; Mon, 26 Nov 2012 19:35:19 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKULQ09890Z/W6QlVGRzIXv+4B4WfYStDu@postini.com; Mon, 26 Nov 2012 19:35:19 PST 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 CC5DE1B81D9 for ; Mon, 26 Nov 2012 19:35:18 -0800 (PST) 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 C1E0019005C; Mon, 26 Nov 2012 19:35:18 -0800 (PST) (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.0318.004; Mon, 26 Nov 2012 19:35:18 -0800 From: Ted Lemon To: Stephen Jacob Thread-Topic: [dhcwg] IP address vs. FQDN discussion Thread-Index: Ac29xfcgXk0oSmncRrej4Wdd4AHprgFXckYAABhv9YAAQkoKgAB3S1WAANbWQAAABN2WgACU+9KAAAAhFYAAAIQGgAAPw2IAAAjD94A= Date: Tue, 27 Nov 2012 03:35:18 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630747414306@mbx-01.win.nominum.com> References: <94C682931C08B048B7A8645303FDC9F36E947B0E73@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E95C9F87B@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E9751E53D@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630747410569@mbx-01.win.nominum.com> <706C6EB5-3833-46B8-B79F-B8A4340669CE@cisco.com> <50B38CE3.5060806@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B6307474137AE@mbx-01.win.nominum.com> <20121126232418.GA1309@shell-too.nominum.com> In-Reply-To: <20121126232418.GA1309@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: <5761B4628B1A9D40892EC2E839D5D6A8@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [dhcwg] IP address vs. FQDN discussion X-BeenThere: dhcwg@ietf.org 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, 27 Nov 2012 03:35:20 -0000 On Nov 26, 2012, at 6:24 PM, Stephen Jacob wrot= e: > 1. When some want to convey multiple addresses in an option that > accepts a single FQDN. Perhaps this just indicates that the > option should accept a list of IP addresses, but in that case > you must manage the lists of IP addresses in the DHCP server > (manually, or by having the server resolve names into [lists of] > addresses (which sucks for the fast path of the DHCP server)). This is a simple matter of programming, and it's the way it's always been d= one. Are people hard-coding IP addresses into DHCP server configurations = to speed up the servers? > 2. When you want to convey addresses which change more frequently > than (or close to as often as) the length of one's DHCP lease. It's extraordinarily rare that a consumer of DHCP information even checks t= o see that it's changed when the lease is renewed. So yes, if there is a = specific application where the DNS TTL needs to be honored, this is a valid= point, but I've never heard of anybody actually implementing such a thing.= A use case isn't a valid use case if there isn't anyone who would actual= ly use it=97that's what the "use" in "use case" means, and what distinguish= es use cases from deployment scenarios. > 3. Sort of a special case of #2: In cases where you have DNS servers > which can hand out lists of addresses that vary depending on the > 'health' of the services running on the servers with those > addresses. This tends to go hand-in-hand with geolocation, often > under the moniker "GSLB". In this case, addresses may potentially > come and go from a name with great frequency. Again, where's the use case. Of course one could *imagine* deployment sce= narios like that, and they even happen in real life for web services, but w= here's the crossover with DHCP? > In any/all of these cases, it may be inconvenient for someone who > doesn't have the needs listed above to use FQDNs, so that seems like > a case for considering providing the option of providing an address. >=20 > So, while I have no love for DHCP options that may contain multiple > different data formats, I do see the value in being able to do so. I would not deny that there is value in providing FQDNs and letting the cli= ent sort it out, but you haven't said anything at all here that makes the c= ase for providing both FQDNs and IP addresses. And "there is value in XXX= " is not sufficient justification for doing things two different ways. It= needs to be true that there is a use case that is not addressed by the one= of the two choices, and another use case that is not addressed by the othe= r.= From mohamed.boucadair@orange.com Tue Nov 27 01:18: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 D240021F8548 for ; Tue, 27 Nov 2012 01:18:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.000, 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 BhKoPkxbjo4P for ; Tue, 27 Nov 2012 01:18:41 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 8BAC721F8536 for ; Tue, 27 Nov 2012 01:18:37 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id AD2E43B434C; Tue, 27 Nov 2012 10:18:15 +0100 (CET) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 82EE927C046; Tue, 27 Nov 2012 10:18:15 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Tue, 27 Nov 2012 10:18:15 +0100 From: To: Kim Kinnear , Ted Lemon Date: Tue, 27 Nov 2012 10:18:14 +0100 Thread-Topic: [dhcwg] IP address vs. FQDN discussion Thread-Index: Ac3L64tkKNOLxdjlRAWRFRIZtDAyTwAkudAA Message-ID: <94C682931C08B048B7A8645303FDC9F36E98722CCF@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E947B0E73@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E95C9F87B@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E9751E53D@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630747410569@mbx-01.win.nominum.com> <706C6EB5-3833-46B8-B79F-B8A4340669CE@cisco.com> In-Reply-To: <706C6EB5-3833-46B8-B79F-B8A4340669CE@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.10.24.110314 Cc: "" , "Bernie Volz \(volz\)" , Andre Kostur , Bud Millwood Subject: Re: [dhcwg] IP address vs. FQDN discussion X-BeenThere: dhcwg@ietf.org 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, 27 Nov 2012 09:18:55 -0000 Dear Kim, Please see inline.=20 Cheers, Med=20 >-----Message d'origine----- >De : dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] De=20 >la part de Kim Kinnear >Envoy=E9 : lundi 26 novembre 2012 16:34 >=C0 : Ted Lemon >Cc : ; Andre Kostur; Bud Millwood; Bernie Volz=20 >(volz); Kim Kinnear >Objet : Re: [dhcwg] IP address vs. FQDN discussion > > >Ted,=20 > >Thank you for stating this so clearly. I was working up to >trying to say pretty much the same thing, but you beat me to it, >and stated it better as well. > >I would add that, having seen real world environments grind to a >halt because they used FQDN's for configuration and DNS servers >were unavailable, Med: This is deployment-specific. In some deployments (e.g., SIP-based mana= ged services offerings), both the DNS and SIP infrastructures are managed b= y the same administrative entity. Some motivations to use the fqdn are disc= ussed in the draft.=20 I cannot see how anyone could want to use an >FQDN when an IP address would do. Med: I see it from another perspective: Having the same option which allows= to switch from returning a name to an IP address would be more adequate as= this does not require to standardize a new option (get a codepoint for the= ip address option if only the fqdn is specified). > >If you absolutely *have* to have an FQDN, then build that into >the draft as the only approach. Med: I can have a favourite approach (e.g., fqdn) given some deployment con= straints but in other deployments the favourite approach would be different= . =20 If you don't *have* to have an >FQDN, then by all means use an IP address and make that the only >approach. Med: IMO, this is difficult to achieve. Having a flexible encoding which al= lows to return an IP address or a name would be a good compromise. As state= d in the I-D: o A DHCP server can be configured to inject one or multiple FQDNs in the option. o A DHCP server can be configured to inject one or multiple IP addresses in the option o A DHCP server can be configured to resolve the FQDN and inject the resolved IP address(es) as IP literals in the option. o A DHCP server can convey in one single option both IPv4 and IPv6 address literals when serving dual-stack clients. > >Regards -- Kim > >On Nov 23, 2012, at 11:28 AM, Ted Lemon wrote: > >> On Nov 23, 2012, at 9:09 AM, Bud Millwood=20 > wrote: >>> To the guys I've CC:ed: Do you support this for DHCPv4? If so, is my >>> concern unfounded? >>=20 >> I have never understood why people want to carry FQDNs in=20 >DHCP packets in the first place, and given the limited size of=20 >DHCPv4 packets, and the compactness of IPv4 addresses, it=20 >really seems like a no-brainer to only support IP addresses. =20 >In the case of IPv6 it's more debatable since IPv6 addresses=20 >are four times larger. ntp.example.com is the same number of=20 >bytes as an IPv6 address. Plus DHCPv6 packets aren't as=20 >restricted in size. >>=20 >> Having said that, there are always people proposing, and=20 >insisting on, FQDNs in DHCP packets. >>=20 >> But here is the core issue to me, and why I oppose this kind=20 >of dual encoding: the encoding is subject to interpretation,=20 >and encourages bad implementations that have undefined failure=20 >modes. My expectation, and what I've heard from people who=20 >advocate sending FQDNs in text strings, is that they'll just=20 >hand the string to some library function that will figure out=20 >whether it's an IP address or an FQDN, and do the right thing. >>=20 >> To me this sounds like begging for problems in the future. =20 >How do we know the library function will do the right thing? =20 >How do we know there isn't a bug in the way the library=20 >function parses these strings? What are the corner cases? =20 >Do IPv6 addresses need to be sent in brackets? Etc. >>=20 >> The beauty of "this is an IPv6 address" is that there's no=20 >interpretation. The beauty of "this is an FQDN encoded in=20 >the standard wire format" is the same. Put it in a text=20 >string, and you lose that. >>=20 >> So my personal opinion on this is that authors of drafts=20 >need to choose: is what you want an FQDN or an IP address? =20 >If you think you want an FQDN, but you sort of want an IP=20 >address as well, rethink your desire for the FQDN, since=20 >clearly it is not necessary. If you are happy to give up=20 >sending an IP address, then you probably do need an FQDN. If=20 >you are not happy to do that, then you probably need an IP=20 >address. You almost certainly do not need both, although I'm=20 >sure you can construct a use case that shows that both would=20 >be nice to have. Nice to have !=3D need. >>=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 mohamed.boucadair@orange.com Tue Nov 27 01:22: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 1EA7E21F84E4 for ; Tue, 27 Nov 2012 01:22:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[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 DKeCh5dqF2pP for ; Tue, 27 Nov 2012 01:22:35 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 783CB21F8557 for ; Tue, 27 Nov 2012 01:22:32 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id C243032440C; Tue, 27 Nov 2012 10:22:31 +0100 (CET) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 8ADE527C067; Tue, 27 Nov 2012 10:22:31 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Tue, 27 Nov 2012 10:22:31 +0100 From: To: Ted Lemon Date: Tue, 27 Nov 2012 10:22:29 +0100 Thread-Topic: [dhcwg] IP address vs. FQDN discussion Thread-Index: Ac29xfcgXk0oSmncRrej4Wdd4AHprgFXckYAABhv9YAAQkoKgAB3S1WAANbWQAAABN2WgAB9PwEAABP0ZAAAGDLHEA== Message-ID: <94C682931C08B048B7A8645303FDC9F36E98722CD3@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E947B0E73@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E95C9F87B@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E9751E53D@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630747410569@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36E987229FD@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630747413582@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630747413582@mbx-01.win.nominum.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.10.24.110314 Cc: "" , Andre Kostur , "Bernie Volz \(volz\)" , Bud Millwood Subject: Re: [dhcwg] IP address vs. FQDN discussion X-BeenThere: dhcwg@ietf.org 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, 27 Nov 2012 09:22:37 -0000 Hi Ted, Please see inline.=20 Cheers, Med=20 >-----Message d'origine----- >De : Ted Lemon [mailto:Ted.Lemon@nominum.com]=20 >Envoy=E9 : lundi 26 novembre 2012 14:46 >=C0 : BOUCADAIR Mohamed OLNC/OLN >Cc : Bud Millwood; ; Bernie Volz (volz); Andre Kostur >Objet : Re: [dhcwg] IP address vs. FQDN discussion > >On Nov 26, 2012, at 7:38 AM, mohamed.boucadair@orange.com wrote: >>> To me this sounds like begging for problems in the future. =20 >>> How do we know the library function will do the right thing? =20 >>> How do we know there isn't a bug in the way the library=20 >>=20 >> Med: We know the behaviour of current name resolution=20 >libraries, so we can define a safe validation procedure for=20 >these libraries. Should we speculate on the evolution of these=20 >name resolution libraries? IMO, I don't think so. Note, DNS=20 >names can be returned in dhcp options but dns is not the only=20 >available name resolution service... > >Right, this is the core of the problem. The problem is=20 >open-ended. If you just send an IP address, you can put all=20 >this complexity on the server, and because it's monolithic,=20 >there's no interoperation, and hence no interoperability=20 >problems. Whereas if you use DHCP as a conduit between=20 >heterogenous hosts, the server implementation has no way to=20 >anticipate what might happen on the client. Med: That's indeed one possible approach but as discussed in the draft this= may not meet the requirements in some deployments. This is the main contri= bution of this draft: investigate an alternative encoding approach which wo= uld allow to meet various deployments. > >> Med: We can make a choice/decision but it may not be=20 >appropriate for all deployments. This is why I do still think=20 >it does not make sense to dictate which option a provider need=20 >to support. There are arguments in favour of an IP address and=20 >other arguments in favour of FQDN. This is what this draft is=20 >trying to achieve in this=20 >section:http://tools.ietf.org/html/draft-boucadair-dhc-address- >name-encoding-02#section-2. > >There are some good arguments here in favor of using an FQDN. =20 > If these arguments are sufficient to justify requiring a=20 >resolver, then you should use an FQDN and not support an IP=20 >address. Otherwise you will have some devices that support=20 >the FQDN, and some that do not, and you will run into=20 >interoperability problems. Med: The dns resolved point is discussed in the draft, see http://tools.iet= f.org/html/draft-boucadair-dhc-address-name-encoding-02#section-2.1.2.=20 > >= From mohamed.boucadair@orange.com Tue Nov 27 01:28: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 A841821F8427 for ; Tue, 27 Nov 2012 01:28:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, 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 0zFhWrBG7y3y for ; Tue, 27 Nov 2012 01:28:41 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id EFB2021F841C for ; Tue, 27 Nov 2012 01:28:12 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 6EFE02DC29D; Tue, 27 Nov 2012 10:28:11 +0100 (CET) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id D355B4C070; Tue, 27 Nov 2012 10:28:10 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Tue, 27 Nov 2012 10:28:10 +0100 From: To: Sten Carlsen , "dhcwg@ietf.org" Date: Tue, 27 Nov 2012 10:28:09 +0100 Thread-Topic: [dhcwg] IP address vs. FQDN discussion Thread-Index: Ac3L7BHvr+1yiIzsRryNJHCoD5k5RwAlLwjw Message-ID: <94C682931C08B048B7A8645303FDC9F36E98722CE0@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E947B0E73@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E95C9F87B@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E9751E53D@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630747410569@mbx-01.win.nominum.com> <706C6EB5-3833-46B8-B79F-B8A4340669CE@cisco.com> <50B38CE3.5060806@s-carlsen.dk> In-Reply-To: <50B38CE3.5060806@s-carlsen.dk> 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_94C682931C08B048B7A8645303FDC9F36E98722CE0PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.24.110314 Subject: Re: [dhcwg] IP address vs. FQDN discussion X-BeenThere: dhcwg@ietf.org 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, 27 Nov 2012 09:28:46 -0000 --_000_94C682931C08B048B7A8645303FDC9F36E98722CE0PUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Sten, This point is discussed in http://tools.ietf.org/html/draft-boucadair-dhc-a= ddress-name-encoding-02#section-2.2.3. Two modes are discussed in that sect= ion: (1) load-balancing procedure which involves DHCP servers (2) load-balancing procedure which does not involve dhcp server The first mode may not be acceptable in some deployments (mainly for operat= ional considerations). Cheers, Med ________________________________ De : dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] De la part de S= ten Carlsen Envoy=E9 : lundi 26 novembre 2012 16:38 =C0 : dhcwg@ietf.org Objet : Re: [dhcwg] IP address vs. FQDN discussion Just a thought, load balancers and other appliances that may have more than= one IP, would they have any relevance for this? If not, then fine, forget = this. On 26/11/12 16:34, Kim Kinnear wrote: Ted, Thank you for stating this so clearly. I was working up to trying to say pretty much the same thing, but you beat me to it, and stated it better as well. I would add that, having seen real world environments grind to a halt because they used FQDN's for configuration and DNS servers were unavailable, I cannot see how anyone could want to use an FQDN when an IP address would do. If you absolutely *have* to have an FQDN, then build that into the draft as the only approach. If you don't *have* to have an FQDN, then by all means use an IP address and make that the only approach. Regards -- Kim On Nov 23, 2012, at 11:28 AM, Ted Lemon wrote: On Nov 23, 2012, at 9:09 AM, Bud Millwood wrote: To the guys I've CC:ed: Do you support this for DHCPv4? If so, is my concern unfounded? I have never understood why people want to carry FQDNs in DHCP packets in t= he first place, and given the limited size of DHCPv4 packets, and the compa= ctness of IPv4 addresses, it really seems like a no-brainer to only support= IP addresses. In the case of IPv6 it's more debatable since IPv6 address= es are four times larger. ntp.example.com is the same number of bytes as = an IPv6 address. Plus DHCPv6 packets aren't as restricted in size. Having said that, there are always people proposing, and insisting on, FQDN= s in DHCP packets. But here is the core issue to me, and why I oppose this kind of dual encodi= ng: the encoding is subject to interpretation, and encourages bad implement= ations that have undefined failure modes. My expectation, and what I've h= eard from people who advocate sending FQDNs in text strings, is that they'l= l just hand the string to some library function that will figure out whethe= r it's an IP address or an FQDN, and do the right thing. To me this sounds like begging for problems in the future. How do we know= the library function will do the right thing? How do we know there isn't= a bug in the way the library function parses these strings? What are the= corner cases? Do IPv6 addresses need to be sent in brackets? Etc. The beauty of "this is an IPv6 address" is that there's no interpretation. = The beauty of "this is an FQDN encoded in the standard wire format" is th= e same. Put it in a text string, and you lose that. So my personal opinion on this is that authors of drafts need to choose: is= what you want an FQDN or an IP address? If you think you want an FQDN, b= ut you sort of want an IP address as well, rethink your desire for the FQDN= , since clearly it is not necessary. If you are happy to give up sending = an IP address, then you probably do need an FQDN. If you are not happy to= do that, then you probably need an IP address. You almost certainly do n= ot need both, although I'm sure you can construct a use case that shows tha= t both would be nice to have. Nice to have !=3D need. _______________________________________________ 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 -- Best regards Sten Carlsen No improvements come from shouting: "MALE BOVINE MANURE!!!" --_000_94C682931C08B048B7A8645303FDC9F36E98722CE0PUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear Sten,
 
This point is discussed in http://tools.ietf.org/html/draft-boucadair-dhc-address-= name-encoding-02#section-2.2.3.=20 Two modes are discussed in that section:
 
(1) load-balancing procedure=20 which involves DHCP servers
(2) load-balancing procedure which does = not=20 involve dhcp server
 
The first mode may not be acceptable in some= =20 deployments (mainly for operational considerations).
 
Cheers,
Med
 

De : dhcwg-bounces@ietf.org=20 [mailto:dhcwg-bounces@ietf.org] De la part de Sten=20 Carlsen
Envoy=E9 : lundi 26 novembre 2012=20 16:38
=C0 : dhcwg@ietf.org
Objet : Re: [dhc= wg] IP=20 address vs. FQDN discussion

Just a thought, load balancers and other appliances that may h= ave=20 more than one IP, would they have any relevance for this? If not, then fi= ne,=20 forget this.

On 26/11/12 16:34, Kim Kinnear wrote:
Ted,=20

Thank you for stating this so clearly.  I was working up to
trying to say pretty much the same thing, but you beat me to it,
and stated it better as well.

I would add that, having seen real world environments grind to a
halt because they used FQDN's for configuration and DNS servers
were unavailable, I cannot see how anyone could want to use an
FQDN when an IP address would do.

If you absolutely *have* to have an FQDN, then build that into
the draft as the only approach.  If you don't *have* to have an
FQDN, then by all means use an IP address and make that the only
approach.

Regards -- Kim

On Nov 23, 2012, at 11:28 AM, Ted Lemon wrote:


On Nov 23, 2012, at 9:09 AM, B=
ud Millwood <budm@weird-solutions.com> wrote:

To the guys I've CC:ed: Do y=
ou support this for DHCPv4? If so, is my
concern unfounded?

I have never understood why people want t=
o carry FQDNs in DHCP packets in the first place, and given the limited siz=
e of DHCPv4 packets, and the compactness of IPv4 addresses, it really seems=
 like a no-brainer to only support IP addresses.   In the case of IPv6 it's=
 more debatable since IPv6 addresses are four times larger.   ntp.example.c=
om is the same number of bytes as an IPv6 address.   Plus DHCPv6 packets ar=
en't as restricted in size.

Having said that, there are always people proposing, and insisting on, FQDN=
s in DHCP packets.

But here is the core issue to me, and why I oppose this kind of dual encodi=
ng: the encoding is subject to interpretation, and encourages bad implement=
ations that have undefined failure modes.   My expectation, and what I've h=
eard from people who advocate sending FQDNs in text strings, is that they'l=
l just hand the string to some library function that will figure out whethe=
r it's an IP address or an FQDN, and do the right thing.

To me this sounds like begging for problems in the future.   How do we know=
 the library function will do the right thing?   How do we know there isn't=
 a bug in the way the library function parses these strings?   What are the=
 corner cases?   Do IPv6 addresses need to be sent in brackets?   Etc.

The beauty of "this is an IPv6 address" is that there's no interpretation. =
  The beauty of "this is an FQDN encoded in the standard wire format" is th=
e same.   Put it in a text string, and you lose that.

So my personal opinion on this is that authors of drafts need to choose: is=
 what you want an FQDN or an IP address?   If you think you want an FQDN, b=
ut you sort of want an IP address as well, rethink your desire for the FQDN=
, since clearly it is not necessary.   If you are happy to give up sending =
an IP address, then you probably do need an FQDN.   If you are not happy to=
 do that, then you probably need an IP address.   You almost certainly do n=
ot need both, although I'm sure you can construct a use case that shows tha=
t both would be nice to have.   Nice to have !=3D need.

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

_________________________________________=
______
dhcwg mailing list
dhcwg@ie=
tf.org
https://www.ietf.org/mailman/listinfo/dhcwg


--=20
Best regards

Sten Carlsen

No improvements come from shouting:
       "MALE BOVINE MANURE!!!"
--_000_94C682931C08B048B7A8645303FDC9F36E98722CE0PUEXCB1Bnante_-- From mohamed.boucadair@orange.com Tue Nov 27 01: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 6DAB421F8574 for ; Tue, 27 Nov 2012 01:30:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.000, 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 ET-LI6MoGrhf for ; Tue, 27 Nov 2012 01:30:30 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id E027821F857A for ; Tue, 27 Nov 2012 01:30:19 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 4B7C93242D9; Tue, 27 Nov 2012 10:30:19 +0100 (CET) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id C796827C072; Tue, 27 Nov 2012 10:30:18 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Tue, 27 Nov 2012 10:30:18 +0100 From: To: Ted Lemon , Sten Carlsen Date: Tue, 27 Nov 2012 10:30:17 +0100 Thread-Topic: [dhcwg] IP address vs. FQDN discussion Thread-Index: Ac29xfcgXk0oSmncRrej4Wdd4AHprgFXckYAABhv9YAAQkoKgAB3S1WAANbWQAAABN2WgACU+9KAAAAhFYAAAIQGgAAUHP9Q Message-ID: <94C682931C08B048B7A8645303FDC9F36E98722CE4@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E947B0E73@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E95C9F87B@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E9751E53D@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630747410569@mbx-01.win.nominum.com> <706C6EB5-3833-46B8-B79F-B8A4340669CE@cisco.com> <50B38CE3.5060806@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B6307474137AE@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307474137AE@mbx-01.win.nominum.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.10.24.110314 Cc: "" Subject: Re: [dhcwg] IP address vs. FQDN discussion X-BeenThere: dhcwg@ietf.org 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, 27 Nov 2012 09:30:30 -0000 Re-, Please see inline.=20 Cheers, Med=20 >-----Message d'origine----- >De : dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] De=20 >la part de Ted Lemon >Envoy=E9 : lundi 26 novembre 2012 16:53 >=C0 : Sten Carlsen >Cc : >Objet : Re: [dhcwg] IP address vs. FQDN discussion > >On Nov 26, 2012, at 10:38 AM, Sten Carlsen wrote: >> Just a thought, load balancers and other appliances that may=20 >have more than one IP, would they have any relevance for this?=20 >If not, then fine, forget this. > >This is mentioned in the draft Med wrote. Of course, the=20 >DHCP server can also do load balancing; it doesn't have to=20 >happen on the client. But any sort of DNS strategy that does=20 >geographical load direction based on a common name would fail,=20 >since the DHCP server and DHCP client are in different locations. > >However, DHCP makes solving this problem easy as well-give out=20 >different information on different networks. All that is=20 >required is that names be chosen for locality, rather than=20 >using the same name in all locations and having the DNS server=20 >give different answers according to location. > >Really, all of the operational issues Med talks about in the=20 >draft _can_ be solved with DHCP server configuration; even the=20 >double indirection problem can be solved by simply configuring=20 >the FQDN on the DHCP server and having the DHCP server hook it=20 >up. The DNS server administrator can change the FQDN, and=20 >the DHCP server will quickly start using the new FQDN=20 >(assuming an appropriate TTL was chosen). Med: I fully agree with you this is technically doable. The main issue is o= perational as mentioned in the draft:=20 Requiring the DHCP server to interface with a DNS-based load distributing engine may not be acceptable for operators separating the delivery of (basic) network connectivity from service-related provisioning. From Francis.Dupont@fdupont.fr Tue Nov 27 13:35:20 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 6647521F8613 for ; Tue, 27 Nov 2012 13:35:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=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 UGrmeGIOX8Dw for ; Tue, 27 Nov 2012 13:35:20 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id 97E5B21F8863 for ; Tue, 27 Nov 2012 13:35:19 -0800 (PST) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id qARLZIBM014961; Tue, 27 Nov 2012 22:35:18 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201211272135.qARLZIBM014961@givry.fdupont.fr> From: Francis Dupont To: Stephen Jacob In-reply-to: Your message of Mon, 26 Nov 2012 15:47:36 PST. <20121126234736.GB1309@shell-too.nominum.com> Date: Tue, 27 Nov 2012 22:35:18 +0100 Sender: Francis.Dupont@fdupont.fr Cc: IETF DHC Working Group Subject: Re: [dhcwg] DHCPv4-over-IPv6 client-side implementations? X-BeenThere: dhcwg@ietf.org 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, 27 Nov 2012 21:35:20 -0000 In your previous mail you wrote: > I know there's at least one group working on an implementation of > the client side of DHCPv4-over-IPv6 (the CRA + ?), but it is not > ready yet as I understand it. => note there is no "DHCPv4-over-IPv6 client" per se if you don't include the [H]CRA inside a client. > Do any of you know if there are any complete or mostly complete > implementations which might be used for, e.g., interop testing? => we (ISC) have an implementation but we are waiting for the CRA6ADDR code point (to be assigned by IANA) before releasing it... Regards Francis.Dupont@fdupont.fr (also fdupont@isc.org) From volz@cisco.com Tue Nov 27 14: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 EFC4D21F8529 for ; Tue, 27 Nov 2012 14:01:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JtB41Tcxd3ee for ; Tue, 27 Nov 2012 14:01:45 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 0BDB021F8528 for ; Tue, 27 Nov 2012 14:01:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3631; q=dns/txt; s=iport; t=1354053705; x=1355263305; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=dW4PKwrZ8KgZuNy1fjf6NfJIGIY9PVNJmVdrXgumjkc=; b=Tp66VPDj/3HbHV3xYDPbOKLwIb/L7ETkhT6AaJTrmnZ7SnKy4a77upHY H4xHi9RpzD0LzGJOljdUyTml5TAs2xQxLIIMQNUPmXMWyRhhpY09jgDcp BxWQr+yVKydHuUs11mRzcrWaFIbMDwfhl9ostXUhxkz4ouKyVUwIsCILb 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAN43tVCtJXG9/2dsb2JhbABFwB8Wc4IeAQEBBAEBATcxAwsMBAIBCBEEAQELFAkHJwsUCQgCBA4FCIgFDK9RkDeMOoNgYQOXHY8ognCCIA X-IronPort-AV: E=McAfee;i="5400,1158,6909"; a="146821607" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-7.cisco.com with ESMTP; 27 Nov 2012 22:01:44 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id qARM1hYl005456 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 27 Nov 2012 22:01:43 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.66]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.001; Tue, 27 Nov 2012 16:01:43 -0600 From: "Bernie Volz (volz)" To: Leaf yeh Thread-Topic: WGLC: draft-ietf-dhc-dhcpv6-radius-opt-04 Thread-Index: AQHNwnuJXxc1SNgKKEqdICsCoFzJ1ZfwcRSggAAN/PCAAfbSAIAK0DpwgAEEITA= Date: Tue, 27 Nov 2012 22:01:43 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E0F5A8DED@xmb-rcd-x04.cisco.com> References: <489D13FBFA9B3E41812EA89F188F018E0F58B2E2@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.86.254.236] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-radius-opt-04 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 22:01:46 -0000 Hi: A few nits: - In section 4, "The OPTION_RADIUS is a stateless DHCPv6 option, " have we = really called options stateless or stateful? I am not sure the distinction = is necessary or even proper? - The text: "Note: The definition of the RADIUS attribute's 'Length' field in section 5 of [RFC2865] is different from that of DHCPv6 option's 'option-len' field defined here." Is a bit weird as option-len really has nothing to do with this. I'd sugges= t: Note: The definition of the RADIUS attribute's 'Length' field in section 5 of [RFC2865] includes the type and length fields. =20 I just figured it was worth reminding folks that the RADIUS attribute lengt= h is different. - In section 3 and 5, RENEW/REBIND/RELAY-FORW is used whereas we usually us= e Renew/Rebind/Relay-Forw for DHCPv6 message names (mixed case), as was don= e earlier (in the diagrams). - In several places "Should" is used when I think you intended to use "SHOU= LD"? (As per section 2 and RFC 2119). - Why isn't the Delegated-IPv6-Prefix attribute (RFC 4818) included in the = list? - Bernie -----Original Message----- From: Leaf yeh [mailto:leaf.y.yeh@huawei.com]=20 Sent: Tuesday, November 27, 2012 1:31 AM To: Bernie Volz (volz) Subject: RE: WGLC: draft-ietf-dhc-dhcpv6-radius-opt-04 Hi Bernie, Hope you've been back to work from the vacation. The attached (ver.-05) is = for your review again and input the comments to dhcwg@ietf.org.=20 Based on the ver.-04 of draft(OPTION_RADIUS), the ver.-05 tries to solve th= e editorial comments from Ted Lemon and Roberta Maglione on the ML of DHC.= =20 The text change includes: a. Replace 'IETF Review' to be 'IETF Expert Review' in section 9; b. Add = 'New RADIUS attributes may be added to this list after the IETF Expert Revi= ew RFC5226].' into section 4. Best Regards, Leaf -----Original Message----- From: Bernie Volz (volz) [mailto:volz@cisco.com] Sent: Tuesday, November 20, 2012 4:00 PM To: Leaf yeh Subject: Re: WGLC: draft-ietf-dhc-dhcpv6-radius-opt-04 I'm on vacation until 11/27. Ping me later that week if you don't hear anyt= hing from me. On 11/18/12 10:01 PM, "Leaf yeh" wrote: >Dear Bernie & Tomek, > >Would you like to review the draft (OPTION_RADIUS) and input your=20 >comments again? > > >Best Regards, >Leaf > > >-----Original Message----- >From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf=20 >Of Ted Lemon >Sent: Wednesday, November 14, 2012 11:20 PM >To: WG >Subject: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-radius-opt-04 > >The authors of this document have requested a working group last call. >The document describes a mechanism, similar to the mechanism in DHCPv4, >for carrying RADIUS options in DHCP packets. If this is of interest to >you, please review the draft: > > http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-radius-opt-04 > >If you have comments, please send them to the working group mailing list. > If you are in favor of advancing the document as it is, please reply to >this message and say so. If you do not favor advancing the document, >and do not have specific comments, please reply to this message=20 >indicating that you don't favor advancing the document. > >Since the document has my name on it, John will be doing the evaluation >of consensus. He will do this on or after November 28. > >Thanks! > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www.ietf.org/mailman/listinfo/dhcwg From leaf.y.yeh@huawei.com Tue Nov 27 18:06: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 C621E1F0C6A for ; Tue, 27 Nov 2012 18:06:16 -0800 (PST) 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 18XSp0UayLNh for ; Tue, 27 Nov 2012 18:06:16 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 82CFA21F8786 for ; Tue, 27 Nov 2012 18:06:15 -0800 (PST) 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 ANF91115; Wed, 28 Nov 2012 02:06:14 +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, 28 Nov 2012 02:06:05 +0000 Received: from SZXEML449-HUB.china.huawei.com (10.82.67.192) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 28 Nov 2012 10:06:14 +0800 Received: from SZXEML546-MBX.china.huawei.com ([169.254.3.214]) by szxeml449-hub.china.huawei.com ([10.82.67.192]) with mapi id 14.01.0323.003; Wed, 28 Nov 2012 10:06:01 +0800 From: Leaf yeh To: "Bernie Volz (volz)" Thread-Topic: WGLC: draft-ietf-dhc-dhcpv6-radius-opt-04 Thread-Index: AQHNwnuJXxc1SNgKKEqdICsCoFzJ1ZfwcRSggAAN/PCAAfbSAIAK0DpwgAEEITCAAEeEAA== Date: Wed, 28 Nov 2012 02:06:00 +0000 Message-ID: References: <489D13FBFA9B3E41812EA89F188F018E0F58B2E2@xmb-rcd-x04.cisco.com> <489D13FBFA9B3E41812EA89F188F018E0F5A8DED@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E0F5A8DED@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: "dhcwg@ietf.org" Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-radius-opt-04 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 02:06:17 -0000 Bernie - Why isn't the Delegated-IPv6-Prefix attribute (RFC 4818) included = in the list? The 2nd line of the list in section 4 shows: Type Code Attribute Reference 26 Vendor-Specific [RFC2865] 123 Delegated-IPv6-Prefix [RFC4818] .... (https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-radius-opt/?include= _text=3D1)=20 The other editorial comments will reply soon. Best Regards, Leaf -----Original Message----- From: Bernie Volz (volz) [mailto:volz@cisco.com]=20 Sent: Wednesday, November 28, 2012 6:02 AM To: Leaf yeh Cc: dhcwg@ietf.org Subject: RE: WGLC: draft-ietf-dhc-dhcpv6-radius-opt-04 Hi: A few nits: - In section 4, "The OPTION_RADIUS is a stateless DHCPv6 option, " have we = really called options stateless or stateful? I am not sure the distinction = is necessary or even proper? - The text: "Note: The definition of the RADIUS attribute's 'Length' field in section 5 of [RFC2865] is different from that of DHCPv6 option's 'option-len' field defined here." Is a bit weird as option-len really has nothing to do with this. I'd sugges= t: Note: The definition of the RADIUS attribute's 'Length' field in section 5 of [RFC2865] includes the type and length fields. =20 I just figured it was worth reminding folks that the RADIUS attribute lengt= h is different. - In section 3 and 5, RENEW/REBIND/RELAY-FORW is used whereas we usually us= e Renew/Rebind/Relay-Forw for DHCPv6 message names (mixed case), as was don= e earlier (in the diagrams). - In several places "Should" is used when I think you intended to use "SHOU= LD"? (As per section 2 and RFC 2119). - Why isn't the Delegated-IPv6-Prefix attribute (RFC 4818) included in the = list? - Bernie -----Original Message----- From: Leaf yeh [mailto:leaf.y.yeh@huawei.com]=20 Sent: Tuesday, November 27, 2012 1:31 AM To: Bernie Volz (volz) Subject: RE: WGLC: draft-ietf-dhc-dhcpv6-radius-opt-04 Hi Bernie, Hope you've been back to work from the vacation. The attached (ver.-05) is = for your review again and input the comments to dhcwg@ietf.org.=20 Based on the ver.-04 of draft(OPTION_RADIUS), the ver.-05 tries to solve th= e editorial comments from Ted Lemon and Roberta Maglione on the ML of DHC.= =20 The text change includes: a. Replace 'IETF Review' to be 'IETF Expert Review' in section 9; b. Add = 'New RADIUS attributes may be added to this list after the IETF Expert Revi= ew RFC5226].' into section 4. Best Regards, Leaf -----Original Message----- From: Bernie Volz (volz) [mailto:volz@cisco.com] Sent: Tuesday, November 20, 2012 4:00 PM To: Leaf yeh Subject: Re: WGLC: draft-ietf-dhc-dhcpv6-radius-opt-04 I'm on vacation until 11/27. Ping me later that week if you don't hear anyt= hing from me. On 11/18/12 10:01 PM, "Leaf yeh" wrote: >Dear Bernie & Tomek, > >Would you like to review the draft (OPTION_RADIUS) and input your=20 >comments again? > > >Best Regards, >Leaf > > >-----Original Message----- >From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf=20 >Of Ted Lemon >Sent: Wednesday, November 14, 2012 11:20 PM >To: WG >Subject: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-radius-opt-04 > >The authors of this document have requested a working group last call. >The document describes a mechanism, similar to the mechanism in DHCPv4, >for carrying RADIUS options in DHCP packets. If this is of interest to >you, please review the draft: > > http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-radius-opt-04 > >If you have comments, please send them to the working group mailing list. > If you are in favor of advancing the document as it is, please reply to >this message and say so. If you do not favor advancing the document, >and do not have specific comments, please reply to this message=20 >indicating that you don't favor advancing the document. > >Since the document has my name on it, John will be doing the evaluation >of consensus. He will do this on or after November 28. > >Thanks! > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www.ietf.org/mailman/listinfo/dhcwg From volz@cisco.com Tue Nov 27 19:07: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 1FE0621E8030 for ; Tue, 27 Nov 2012 19:07:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.516 X-Spam-Level: X-Spam-Status: No, score=-9.516 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, URIBL_RHS_DOB=1.083] 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 dAabW5nThjnS for ; Tue, 27 Nov 2012 19:07:54 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id B95C921F8767 for ; Tue, 27 Nov 2012 19:07:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4785; q=dns/txt; s=iport; t=1354072074; x=1355281674; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=N3R5RR8wAeFkMiSmQj+DcZgpN8CqreBWjfPm60TZnis=; b=jM3T8VktBOFL2AooBSwZ8Uj1DhQ0RktiGyE4pGNjEwDaSt/+tVaxR+5X ihHX0Mr5teePT527bMdW1pw23qs35xBoriuHeDqQsCkU3Lbs+k2wbt2e8 acL12uf7aodpKaOWMZ3GzqH9I7ZqzqUweGl+9t0s73ZugRKqB/JEQEqYo I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAD1/tVCtJXG//2dsb2JhbABFwCMWc4IeAQEBAwEBAQE3MQMLBQcEAgEIEQQBAQEdAQkHJwsUCQgCBA4FiAcGDLEnjg+MOoNgYQOWAYEcjyiCYw0 X-IronPort-AV: E=McAfee;i="5400,1158,6909"; a="146901204" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-5.cisco.com with ESMTP; 28 Nov 2012 03:07:43 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id qAS37hGF001908 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 28 Nov 2012 03:07:43 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.66]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.001; Tue, 27 Nov 2012 21:07:42 -0600 From: "Bernie Volz (volz)" To: Leaf yeh Thread-Topic: WGLC: draft-ietf-dhc-dhcpv6-radius-opt-04 Thread-Index: AQHNwnuJXxc1SNgKKEqdICsCoFzJ1ZfwcRSggAAN/PCAAfbSAIAK0DpwgAEEITCAAEeEAIAAFFdm Date: Wed, 28 Nov 2012 03:07:41 +0000 Message-ID: <5B110117-5EA7-4565-8676-CC022A9790E4@cisco.com> References: <489D13FBFA9B3E41812EA89F188F018E0F58B2E2@xmb-rcd-x04.cisco.com> <489D13FBFA9B3E41812EA89F188F018E0F5A8DED@xmb-rcd-x04.cisco.com>, In-Reply-To: Accept-Language: en-US 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 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-radius-opt-04 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 03:07:56 -0000 Oops ... Sorry. Sent from my iPad On Nov 27, 2012, at 9:06 PM, "Leaf yeh" wrote: > Bernie - Why isn't the Delegated-IPv6-Prefix attribute (RFC 4818) include= d in the list? >=20 > The 2nd line of the list in section 4 shows: >=20 > Type Code Attribute Reference > 26 Vendor-Specific [RFC2865] > 123 Delegated-IPv6-Prefix [RFC4818] > .... > (https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-radius-opt/?inclu= de_text=3D1)=20 >=20 > The other editorial comments will reply soon. >=20 >=20 > Best Regards, > Leaf >=20 >=20 >=20 > -----Original Message----- > From: Bernie Volz (volz) [mailto:volz@cisco.com]=20 > Sent: Wednesday, November 28, 2012 6:02 AM > To: Leaf yeh > Cc: dhcwg@ietf.org > Subject: RE: WGLC: draft-ietf-dhc-dhcpv6-radius-opt-04 >=20 > Hi: >=20 > A few nits: > - In section 4, "The OPTION_RADIUS is a stateless DHCPv6 option, " have w= e really called options stateless or stateful? I am not sure the distinctio= n is necessary or even proper? >=20 > - The text: > "Note: The definition of the RADIUS attribute's 'Length' field in > section 5 of [RFC2865] is different from that of DHCPv6 option's > 'option-len' field defined here." >=20 > Is a bit weird as option-len really has nothing to do with this. I'd sugg= est: >=20 > Note: The definition of the RADIUS attribute's 'Length' field in > section 5 of [RFC2865] includes the type and length fields. >=20 > I just figured it was worth reminding folks that the RADIUS attribute len= gth is different. >=20 > - In section 3 and 5, RENEW/REBIND/RELAY-FORW is used whereas we usually = use Renew/Rebind/Relay-Forw for DHCPv6 message names (mixed case), as was d= one earlier (in the diagrams). >=20 > - In several places "Should" is used when I think you intended to use "SH= OULD"? (As per section 2 and RFC 2119). >=20 > - Why isn't the Delegated-IPv6-Prefix attribute (RFC 4818) included in th= e list? >=20 >=20 > - Bernie >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Leaf yeh [mailto:leaf.y.yeh@huawei.com]=20 > Sent: Tuesday, November 27, 2012 1:31 AM > To: Bernie Volz (volz) > Subject: RE: WGLC: draft-ietf-dhc-dhcpv6-radius-opt-04 >=20 > Hi Bernie, >=20 > Hope you've been back to work from the vacation. The attached (ver.-05) i= s for your review again and input the comments to dhcwg@ietf.org.=20 >=20 > Based on the ver.-04 of draft(OPTION_RADIUS), the ver.-05 tries to solve = the editorial comments from Ted Lemon and Roberta Maglione on the ML of DHC= .=20 >=20 > The text change includes: >=20 > a. Replace 'IETF Review' to be 'IETF Expert Review' in section 9; b. Ad= d 'New RADIUS attributes may be added to this list after the IETF Expert Re= view RFC5226].' into section 4. >=20 >=20 > Best Regards, > Leaf >=20 >=20 >=20 > -----Original Message----- > From: Bernie Volz (volz) [mailto:volz@cisco.com] > Sent: Tuesday, November 20, 2012 4:00 PM > To: Leaf yeh > Subject: Re: WGLC: draft-ietf-dhc-dhcpv6-radius-opt-04 >=20 > I'm on vacation until 11/27. Ping me later that week if you don't hear an= ything from me. >=20 > On 11/18/12 10:01 PM, "Leaf yeh" wrote: >=20 >> Dear Bernie & Tomek, >>=20 >> Would you like to review the draft (OPTION_RADIUS) and input your=20 >> comments again? >>=20 >>=20 >> Best Regards, >> Leaf >>=20 >>=20 >> -----Original Message----- >> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf=20 >> Of Ted Lemon >> Sent: Wednesday, November 14, 2012 11:20 PM >> To: WG >> Subject: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-radius-opt-04 >>=20 >> The authors of this document have requested a working group last call. >> The document describes a mechanism, similar to the mechanism in DHCPv4, >> for carrying RADIUS options in DHCP packets. If this is of interest to >> you, please review the draft: >>=20 >> http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-radius-opt-04 >>=20 >> If you have comments, please send them to the working group mailing list= . >> If you are in favor of advancing the document as it is, please reply to >> this message and say so. If you do not favor advancing the document, >> and do not have specific comments, please reply to this message=20 >> indicating that you don't favor advancing the document. >>=20 >> Since the document has my name on it, John will be doing the evaluation >> of consensus. He will do this on or after November 28. >>=20 >> Thanks! >>=20 >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg >=20 From sunqi.thu@gmail.com Tue Nov 27 21:19: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 6735D21F859D for ; Tue, 27 Nov 2012 21:19:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dhVr9oqcODr7 for ; Tue, 27 Nov 2012 21:19:28 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id ACEB921E804D for ; Tue, 27 Nov 2012 21:19:28 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id hz11so7279780pad.31 for ; Tue, 27 Nov 2012 21:19:28 -0800 (PST) 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=H+Ly6bJHM0eLzx6zavERMOpSb468fYQfjqbBH5yxvoM=; b=iLd9ZKlC9VZ+3RKjrpIMKomPnijt9D/BARr70fuvBc81S9FxmDSHyxqDWrD9H7SfRS 6zkFneVXajb6yUKoWVrEuGDbT4NTkdAkk5NjuQuxcZfbTQEUNaB2d4POxFEz5rvu4RwE WIHw1bWH4waTtckZAWWca9B/ZrUfjHMF5m+WQPdAQ+gZbN/c12YLdQGPH1LrUmS7prqu PMeshVPCH/MmNLheonze0rYofjdyHYrSbgWADPkjcM0PIL2qQu1gxcV2iFuLrAT6CYMe wuJVhfw3+ASfAlOn41ACPEmp+DyTGsQhzSWSYNea6/VB2nM2vWRwF6LlQVvGodeZWkMY UZNQ== Received: by 10.68.137.234 with SMTP id ql10mr54558032pbb.158.1354079968493; Tue, 27 Nov 2012 21:19:28 -0800 (PST) Received: from [192.168.0.106] ([114.255.41.137]) by mx.google.com with ESMTPS id qp6sm11829563pbc.25.2012.11.27.21.19.21 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 27 Nov 2012 21:19:27 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-1--36884499 From: Qi Sun In-Reply-To: <201211272135.qARLZIBM014961@givry.fdupont.fr> Date: Wed, 28 Nov 2012 13:19:13 +0800 Message-Id: <534F8575-7E02-4E14-8ACE-65173676F255@gmail.com> References: <201211272135.qARLZIBM014961@givry.fdupont.fr> To: Francis Dupont , Stephen Jacob X-Mailer: Apple Mail (2.1084) Cc: IETF DHC Working Group , Cong Liu Subject: Re: [dhcwg] DHCPv4-over-IPv6 client-side implementations? X-BeenThere: dhcwg@ietf.org 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, 28 Nov 2012 05:19:29 -0000 --Apple-Mail-1--36884499 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear all , We have uploaded to Github the source code of our implementations of = DHCPv4-over-IPv6 and lightweight 4over6, implemented by Tsinghua = University.=20 Please can you download the source code via the following links: https://github.com/gnocuil/lightweight4over6 https://github.com/gnocuil/DHCPv4-over-v6 Currently, we use option code 224 for port set option.=20 Your tests and comments are warmly welcome.=20 Please feel free to let us know if there is any issue. Best Regards! Qi Sun On 2012-11-28, at =E4=B8=8A=E5=8D=885:35, Francis Dupont wrote: > In your previous mail you wrote: >=20 >> I know there's at least one group working on an implementation of >> the client side of DHCPv4-over-IPv6 (the CRA + ?), but it is not >> ready yet as I understand it. >=20 > =3D> note there is no "DHCPv4-over-IPv6 client" per se if you don't > include the [H]CRA inside a client. >=20 >> Do any of you know if there are any complete or mostly complete >> implementations which might be used for, e.g., interop testing? >=20 > =3D> we (ISC) have an implementation but we are waiting for the = CRA6ADDR > code point (to be assigned by IANA) before releasing it... >=20 > Regards >=20 > Francis.Dupont@fdupont.fr (also fdupont@isc.org) > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg --Apple-Mail-1--36884499 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Dear all ,

We have uploaded to Github the = source code of our implementations of DHCPv4-over-IPv6 and lightweight = 4over6, implemented by Tsinghua University. 

Please can you download the = source code via the following links:

Currently, we use option = code 224 for port set option. 

Your = tests and comments are warmly welcome. 



Best Regards!

Qi = Sun


On 2012-11-28, at =E4=B8=8A=E5=8D=885:35, Francis Dupont = wrote:

In your previous mail you wrote:

I know there's at least one group working on an = implementation of
the client = side of DHCPv4-over-IPv6 (the CRA + ?), but it is = not
ready yet as I understand = it.

=3D> note there is no "DHCPv4-over-IPv6 = client" per se if you don't
include the [H]CRA inside a = client.

Do any of you know if there = are any complete or mostly complete
implementations which might be used for, e.g., interop = testing?

=3D> we (ISC) have an implementation but = we are waiting for the CRA6ADDR
code point (to be assigned by IANA) = before releasing it...

Regards

Francis.Dupont@fdupont.fr = (also fdupont@isc.org)
__________________= _____________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/= mailman/listinfo/dhcwg

= --Apple-Mail-1--36884499-- From Stephen.Jacob@nominum.com Tue Nov 27 23:14: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 642DD21F86D1 for ; Tue, 27 Nov 2012 23:14:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, 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 dp1r6ENM6fSh for ; Tue, 27 Nov 2012 23:14:55 -0800 (PST) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id 8F32421F86AE for ; Tue, 27 Nov 2012 23:14:55 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKULW57ClAg8l7lsOoeCQcP0irDusSzeYl@postini.com; Tue, 27 Nov 2012 23:14:55 PST Received: by shell-too.nominum.com (Postfix, from userid 11053) id 3A1C91B816D; Tue, 27 Nov 2012 23:14:52 -0800 (PST) Date: Tue, 27 Nov 2012 23:14:52 -0800 From: Stephen Jacob To: Francis Dupont Message-ID: <20121128071452.GB3950@shell-too.nominum.com> Mail-Followup-To: Francis Dupont , Stephen Jacob , IETF DHC Working Group References: <20121126234736.GB1309@shell-too.nominum.com> <201211272135.qARLZIBM014961@givry.fdupont.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201211272135.qARLZIBM014961@givry.fdupont.fr> User-Agent: Mutt/1.4.2.2i X-URI: http://www.nominum.com/ Organization: Nominum, Inc. Cc: IETF DHC Working Group Subject: Re: [dhcwg] DHCPv4-over-IPv6 client-side implementations? X-BeenThere: dhcwg@ietf.org 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, 28 Nov 2012 07:14:56 -0000 On Tue, Nov 27, 2012 at 10:35:18PM +0100, Francis Dupont wrote: > In your previous mail you wrote: > > > I know there's at least one group working on an implementation of > > the client side of DHCPv4-over-IPv6 (the CRA + ?), but it is not > > ready yet as I understand it. > > => note there is no "DHCPv4-over-IPv6 client" per se if you don't > include the [H]CRA inside a client. Right. I was thinking of the CRA and related options. You are, of course, right that there is no "DHCPv4-over-IPv6 client". It wasn't my intention to imply that there was. Since they're all just CRAs from the DHCP server (TSV) perspective (handled the same, that is), as a server implementor I haven't been worrying about LCRA vs. HCRA. > > Do any of you know if there are any complete or mostly complete > > implementations which might be used for, e.g., interop testing? > > => we (ISC) have an implementation but we are waiting for the CRA6ADDR > code point (to be assigned by IANA) before releasing it... Yeah, I'm waiting for the IANA assignment for CRA6ADDR too. Though it requires no special handling by the DHCP server from a protocol standpoint, it will be good to be able to represent it properly in the server. I look forward to trying out ISC's CRA implementation when it is made available. Regards, Stephen -- Stephen Jacob | Stephen.Jacob@nominum.com | +1 650 381 6051 Nominum, Inc. | http://www.nominum.com/ | +1 650 381 6000 From leaf.y.yeh@huawei.com Wed Nov 28 02:21: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 B589121F84EE for ; Wed, 28 Nov 2012 02:21:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, 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 M6EkTQL+GQUJ for ; Wed, 28 Nov 2012 02:21:37 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D86CB21F84E1 for ; Wed, 28 Nov 2012 02:21:36 -0800 (PST) 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 ANH21775; Wed, 28 Nov 2012 10:21:35 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 28 Nov 2012 10:21:25 +0000 Received: from SZXEML422-HUB.china.huawei.com (10.82.67.161) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 28 Nov 2012 10:21:34 +0000 Received: from SZXEML546-MBX.china.huawei.com ([169.254.3.214]) by szxeml422-hub.china.huawei.com ([10.82.67.161]) with mapi id 14.01.0323.003; Wed, 28 Nov 2012 18:21:28 +0800 From: Leaf yeh To: Stephen Jacob , Francis Dupont Thread-Topic: [dhcwg] DHCPv4-over-IPv6 client-side implementations? Thread-Index: AQHNzOcYdPlrnlo6JkeHSmLmDLqfWJf+UDMAgACNNiA= Date: Wed, 28 Nov 2012 10:21:27 +0000 Message-ID: References: <20121126234736.GB1309@shell-too.nominum.com> <201211272135.qARLZIBM014961@givry.fdupont.fr> <20121128071452.GB3950@shell-too.nominum.com> In-Reply-To: <20121128071452.GB3950@shell-too.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: IETF DHC Working Group Subject: Re: [dhcwg] DHCPv4-over-IPv6 client-side implementations? X-BeenThere: dhcwg@ietf.org 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, 28 Nov 2012 10:21:38 -0000 Stephen - ...the client side of DHCPv4-over-IPv6 (the CRA + ?) ... Francis - ...there is no "DHCPv4-over-IPv6 client" per se if you don't incl= ude the [H]CRA inside a client. Section 3 @ https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv4-over-ipv= 6/?include_text=3D1=20 o Client Relay Agent(CRA): a special DHCPv4 Relay Agent which relays between DHCPv4 client and DHCPv4 server using an IPv6 network. A CRA either sits on the same, IPv6-accessable host with the DHCPv4 client, or sits on the same link with the host. o Host Client Relay Agent(HCRA): a CRA which sits on the same, IPv6- accessible host with the DHCPv4 client. o On-Link Client Relay Agent(LCRA): a CRA which sits on the same link with the host that runs DHCPv4 client. LCRA sounds a IPv6-Transport (4o6) client-side RA in this DHCP (4o6) archit= ecture, not really client (C) there. This RA has both IPv6 and IPv4 connect= ivity, and relays DHCP messages between client and IPv6-Transport (4o6) ser= ver-side RA or IPv6-Transport (4o6) server. o IPv6-Transport Relay Agent(TRA): a DHCPv4 Relay Agent that supports IPv6 transport. TRA sits on a machine which has both IPv6 and IPv4 connectivity, and relays DHCP messages between CRA and regular DHCPv4 server. Unlike CRA, TRA sits on the remote end of IPv6 network, and communicates with DHCPv4 server through IPv4. The device sounds a IPv6-Transport (4o6) server-side RA. So the architecture of DHCP4o6 sounds to be: DHCPv4 Client --- IPv6-Transport client-side Relay agent --- IPv6-Transport= server-side Relay agent --- DHCPv4 Server. The IPv6-Transport client-side Relay agent in this architecture sounds a 'c= lient-side 4o6 RA'. The IPv6-Transport server-side Relay agent in this architecture sounds a 's= erver-side 4o6 RA'. The client in this architecture has the variation to combine DHCPv4 Client = and IPv6-Transport client-side Relay agent to be a real 'client-4o6-RA' or = 'Host-4o6-RA'.=20 The server in this architecture has the variation to direct support IPv6-Tr= ansport as a real '4o6-server'. Just for another naming game. Best Regards, Leaf -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of S= tephen Jacob Sent: Wednesday, November 28, 2012 3:15 PM To: Francis Dupont Cc: IETF DHC Working Group Subject: Re: [dhcwg] DHCPv4-over-IPv6 client-side implementations? On Tue, Nov 27, 2012 at 10:35:18PM +0100, Francis Dupont wrote: > In your previous mail you wrote: >=20 > > I know there's at least one group working on an implementation of > > the client side of DHCPv4-over-IPv6 (the CRA + ?), but it is not > > ready yet as I understand it. >=20 > =3D> note there is no "DHCPv4-over-IPv6 client" per se if you don't > include the [H]CRA inside a client. Right. I was thinking of the CRA and related options. You are, of course, right that there is no "DHCPv4-over-IPv6 client". It wasn't my intention to imply that there was. Since they're all just CRAs from the DHCP server (TSV) perspective (handled the same, that is), as a server implementor I haven't been worrying about LCRA vs. HCRA. > > Do any of you know if there are any complete or mostly complete > > implementations which might be used for, e.g., interop testing? >=20 > =3D> we (ISC) have an implementation but we are waiting for the CRA6ADDR > code point (to be assigned by IANA) before releasing it... Yeah, I'm waiting for the IANA assignment for CRA6ADDR too. Though it requires no special handling by the DHCP server from a protocol standpoint, it will be good to be able to represent it properly in the server. I look forward to trying out ISC's CRA implementation when it is made available. 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 leaf.y.yeh@huawei.com Wed Nov 28 03:28: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 C257D21F862A for ; Wed, 28 Nov 2012 03:28:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 ss7xBpyti+Rd for ; Wed, 28 Nov 2012 03:28:25 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 30FEF21F85A3 for ; Wed, 28 Nov 2012 03:28:24 -0800 (PST) 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 ALZ34055; Wed, 28 Nov 2012 11:28:22 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 28 Nov 2012 11:28:12 +0000 Received: from SZXEML420-HUB.china.huawei.com (10.82.67.159) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 28 Nov 2012 11:28:21 +0000 Received: from SZXEML546-MBX.china.huawei.com ([169.254.3.214]) by szxeml420-hub.china.huawei.com ([10.82.67.159]) with mapi id 14.01.0323.003; Wed, 28 Nov 2012 19:28:18 +0800 From: Leaf yeh To: "Bernie Volz (volz)" Thread-Topic: WGLC: draft-ietf-dhc-dhcpv6-radius-opt-04 Thread-Index: AQHNwnuJXxc1SNgKKEqdICsCoFzJ1ZfwcRSggAAN/PCAAfbSAIAK0DpwgAEEITCAAEeEAIAAjbGQ Date: Wed, 28 Nov 2012 11:28:18 +0000 Message-ID: References: <489D13FBFA9B3E41812EA89F188F018E0F58B2E2@xmb-rcd-x04.cisco.com> <489D13FBFA9B3E41812EA89F188F018E0F5A8DED@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" Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-radius-opt-04 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 11:28:25 -0000 Bernie - In section 4, "The OPTION_RADIUS is a stateless DHCPv6 option, " h= ave we really called options stateless or stateful? I am not sure the disti= nction is necessary or even proper? We have the RFC3736, "Stateless Dynamic Host Configuration Protocol (DHCP) = Service for IPv6". I think the 'stateless' in section 4 sounds the same mea= ning as that in RFC3736. Bernie - I'd suggest: Note: The definition of the RADIUS attribute's 'Length' field in section 5 of [RFC2865] includes the type' and length fields. I just figured it was worth reminding folks that the RADIUS attribute lengt= h is different. I am ok with your text, even though I can't see the difference between your= s and mine. It will be "Note: The definition of the RADIUS attribute's 'Len= gth' field in section 5 of [RFC2865] includes the length of 'Type' and 'Len= gth' fields." Bernie - In section 3 and 5, RENEW/REBIND/RELAY-FORW is used whereas we usu= ally use Renew/Rebind/Relay-Forw for DHCPv6 message names (mixed case), as = was done earlier (in the diagrams). I used the words defined in section 24.2 of RFC3315 for the text body in th= is draft. RELAY-FORW means Relay-forward message of DHCPv6, I regard they a= re exactly the same. Bernie - In several places "Should" is used when I think you intended to us= e "SHOULD"? (As per section 2 and RFC 2119). Appreciates. I found 2 'Should' will be replaced by 'SHOULD'. Best Regards, Leaf -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of L= eaf yeh Sent: Wednesday, November 28, 2012 10:06 AM To: Bernie Volz (volz) Cc: dhcwg@ietf.org Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-radius-opt-04 Bernie - Why isn't the Delegated-IPv6-Prefix attribute (RFC 4818) included = in the list? The 2nd line of the list in section 4 shows: Type Code Attribute Reference 26 Vendor-Specific [RFC2865] 123 Delegated-IPv6-Prefix [RFC4818] .... (https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-radius-opt/?include= _text=3D1)=20 The other editorial comments will reply soon. Best Regards, Leaf -----Original Message----- From: Bernie Volz (volz) [mailto:volz@cisco.com]=20 Sent: Wednesday, November 28, 2012 6:02 AM To: Leaf yeh Cc: dhcwg@ietf.org Subject: RE: WGLC: draft-ietf-dhc-dhcpv6-radius-opt-04 Hi: A few nits: - In section 4, "The OPTION_RADIUS is a stateless DHCPv6 option, " have we = really called options stateless or stateful? I am not sure the distinction = is necessary or even proper? - The text: "Note: The definition of the RADIUS attribute's 'Length' field in section 5 of [RFC2865] is different from that of DHCPv6 option's 'option-len' field defined here." Is a bit weird as option-len really has nothing to do with this. I'd sugges= t: Note: The definition of the RADIUS attribute's 'Length' field in section 5 of [RFC2865] includes the type and length fields. =20 I just figured it was worth reminding folks that the RADIUS attribute lengt= h is different. - In section 3 and 5, RENEW/REBIND/RELAY-FORW is used whereas we usually us= e Renew/Rebind/Relay-Forw for DHCPv6 message names (mixed case), as was don= e earlier (in the diagrams). - In several places "Should" is used when I think you intended to use "SHOU= LD"? (As per section 2 and RFC 2119). - Why isn't the Delegated-IPv6-Prefix attribute (RFC 4818) included in the = list? - Bernie -----Original Message----- From: Leaf yeh [mailto:leaf.y.yeh@huawei.com]=20 Sent: Tuesday, November 27, 2012 1:31 AM To: Bernie Volz (volz) Subject: RE: WGLC: draft-ietf-dhc-dhcpv6-radius-opt-04 Hi Bernie, Hope you've been back to work from the vacation. The attached (ver.-05) is = for your review again and input the comments to dhcwg@ietf.org.=20 Based on the ver.-04 of draft(OPTION_RADIUS), the ver.-05 tries to solve th= e editorial comments from Ted Lemon and Roberta Maglione on the ML of DHC.= =20 The text change includes: a. Replace 'IETF Review' to be 'IETF Expert Review' in section 9; b. Add = 'New RADIUS attributes may be added to this list after the IETF Expert Revi= ew RFC5226].' into section 4. Best Regards, Leaf -----Original Message----- From: Bernie Volz (volz) [mailto:volz@cisco.com] Sent: Tuesday, November 20, 2012 4:00 PM To: Leaf yeh Subject: Re: WGLC: draft-ietf-dhc-dhcpv6-radius-opt-04 I'm on vacation until 11/27. Ping me later that week if you don't hear anyt= hing from me. On 11/18/12 10:01 PM, "Leaf yeh" wrote: >Dear Bernie & Tomek, > >Would you like to review the draft (OPTION_RADIUS) and input your=20 >comments again? > > >Best Regards, >Leaf > > >-----Original Message----- >From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf=20 >Of Ted Lemon >Sent: Wednesday, November 14, 2012 11:20 PM >To: WG >Subject: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-radius-opt-04 > >The authors of this document have requested a working group last call. >The document describes a mechanism, similar to the mechanism in DHCPv4, >for carrying RADIUS options in DHCP packets. If this is of interest to >you, please review the draft: > > http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-radius-opt-04 > >If you have comments, please send them to the working group mailing list. > If you are in favor of advancing the document as it is, please reply to >this message and say so. If you do not favor advancing the document, >and do not have specific comments, please reply to this message=20 >indicating that you don't favor advancing the document. > >Since the document has my name on it, John will be doing the evaluation >of consensus. He will do this on or after November 28. > >Thanks! > >_______________________________________________ >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 Wed Nov 28 15:30: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 CE12F21F88E9 for ; Wed, 28 Nov 2012 15:30:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ogUHw0GrRZ1m for ; Wed, 28 Nov 2012 15:30:15 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1810621F841C for ; Wed, 28 Nov 2012 15:30:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1859; q=dns/txt; s=iport; t=1354145415; x=1355355015; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=tkQAFQeebSibFRw0zjIIlLsRmBhEgyR+IZtonyWawgw=; b=Lec5csGMPdbvK76p7sO4zPXVUXq5P5PrWXVp7IACGbak+jdRDtZhKVFl xn1UxpB/rPvRSws9oQYVZrzlBC9oXyRMk7bPGDyUZudunv5WVD+pZrxBh LQoVo7KtL14qhEZ6SfIEFor16v8ZJueT7ggJgxVTX3BmgKlJU0Jn3rL0a c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAO+dtlCtJXG+/2dsb2JhbABFwCIWc4IfAQEEOj8QAgEIIhQQMiUCBAENDYgIvyGMSoNVYQOmRYJygWw1 X-IronPort-AV: E=McAfee;i="5400,1158,6910"; a="147084132" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 28 Nov 2012 23:30:14 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id qASNUEqL015403 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 28 Nov 2012 23:30:14 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.66]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.001; Wed, 28 Nov 2012 17:30:14 -0600 From: "Bernie Volz (volz)" To: "mohamed.boucadair@orange.com" , Ted Lemon Thread-Topic: [dhcwg] IP address vs. FQDN discussion Thread-Index: Ac3ES5usC9GRuubMQsaiLqHZGN/nqAB3HovAAOOVSQAABN1xAACU+/iAAAAhFYAAAIRSgAAk7QCAAEHyi8A= Date: Wed, 28 Nov 2012 23:30:13 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E0F5AC6FA@xmb-rcd-x04.cisco.com> References: <94C682931C08B048B7A8645303FDC9F36E947B0E73@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E95C9F87B@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E9751E53D@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630747410569@mbx-01.win.nominum.com> <706C6EB5-3833-46B8-B79F-B8A4340669CE@cisco.com> <50B38CE3.5060806@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B6307474137AE@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36E98722CE4@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E98722CE4@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.245.109] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [dhcwg] IP address vs. FQDN discussion X-BeenThere: dhcwg@ietf.org 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, 28 Nov 2012 23:30:15 -0000 I think there was some discussion that I may have been the cause of all of = this? I don't recall the particular email or discussion that might have tri= ggered this, but I do recall several drafts proposing to use two options (o= r sub-options) - one for carrying the IPv4 address and another an FQDN - fo= r a particular configuration parameter. I also recall some other drafts pro= posing a type enumerator followed by the data (based on the type enumerator= ). And, I do recall suggesting that the DHC WG perhaps take this issue up t= o provide some guidance as to what is the best practice (perhaps in the Opt= ions Guideline document). Personally, I do not like the idea of two options= (or sub-options) and an enumeration type followed by appropriate data seem= s less desirable over picking one and living with it. As already covered in the discussion, the problem is also not that simple b= ecause there are many considerations - who will use the information, how so= on will it be used, who can manage the information (using an FQDN requires = that the name is in DNS), ... And, perhaps this discussion will leave us where we were with no clear answ= er; but perhaps more details added to draft-ietf-dhc-option-guidelines to a= ssist people in making a decision (I think Tomek indicated that he has an 0= 9 pending with more to say on this matter). --- BTW: draft-boucadair-dhc-address-name-encoding-02 isn't that bad as it prop= oses using strings acceptable to getaddrinfo. Though I am not sure that the= se strings are that tightly specified. And, there are still cases where an = IP address would be required (4-byte or 16-byte option data) - as a DNS res= olver might not be available (if bootstrap loader, etc.) or result in a cat= ch-22 (DNS server's list). And others where a FQDN is required. - Bernie From mohamed.boucadair@orange.com Wed Nov 28 23:40: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 23DBB21F88C2 for ; Wed, 28 Nov 2012 23:40:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.293 X-Spam-Level: X-Spam-Status: No, score=-2.293 tagged_above=-999 required=5 tests=[AWL=-0.045, 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 SbyD+rRREBN2 for ; Wed, 28 Nov 2012 23:40:20 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 0731921F8C18 for ; Wed, 28 Nov 2012 23:40:20 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id D77AE2DC443; Thu, 29 Nov 2012 08:40:18 +0100 (CET) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id B0D3827C064; Thu, 29 Nov 2012 08:40:18 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Thu, 29 Nov 2012 08:40:18 +0100 From: To: "Bernie Volz (volz)" , Ted Lemon Date: Thu, 29 Nov 2012 08:40:17 +0100 Thread-Topic: [dhcwg] IP address vs. FQDN discussion Thread-Index: Ac3ES5usC9GRuubMQsaiLqHZGN/nqAB3HovAAOOVSQAABN1xAACU+/iAAAAhFYAAAIRSgAAk7QCAAEHyi8AAEbBBcA== Message-ID: <94C682931C08B048B7A8645303FDC9F36E98AB155A@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E947B0E73@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E95C9F87B@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E9751E53D@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630747410569@mbx-01.win.nominum.com> <706C6EB5-3833-46B8-B79F-B8A4340669CE@cisco.com> <50B38CE3.5060806@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B6307474137AE@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36E98722CE4@PUEXCB1B.nanterre.francetelecom.fr> <489D13FBFA9B3E41812EA89F188F018E0F5AC6FA@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E0F5AC6FA@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.11.29.5415 Cc: "" Subject: Re: [dhcwg] IP address vs. FQDN discussion X-BeenThere: dhcwg@ietf.org 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, 29 Nov 2012 07:40:21 -0000 Dear Benrie, Please see inline.=20 Cheers, Med =20 >-----Message d'origine----- >De : Bernie Volz (volz) [mailto:volz@cisco.com]=20 >Envoy=E9 : jeudi 29 novembre 2012 00:30 >=C0 : BOUCADAIR Mohamed OLNC/OLN; Ted Lemon >Cc : >Objet : RE: [dhcwg] IP address vs. FQDN discussion > >I think there was some discussion that I may have been the=20 >cause of all of this? I don't recall the particular email or=20 >discussion that might have triggered this, but I do recall=20 >several drafts proposing to use two options (or sub-options) -=20 >one for carrying the IPv4 address and another an FQDN - for a=20 >particular configuration parameter. I also recall some other=20 >drafts proposing a type enumerator followed by the data (based=20 >on the type enumerator). And, I do recall suggesting that the=20 >DHC WG perhaps take this issue up to provide some guidance as=20 >to what is the best practice (perhaps in the Options Guideline=20 >document). Personally, I do not like the idea of two options=20 >(or sub-options) and an enumeration type followed by=20 >appropriate data seems less desirable over picking one and=20 >living with it. > >As already covered in the discussion, the problem is also not=20 >that simple because there are many considerations - who will=20 >use the information, how soon will it be used, who can manage=20 >the information (using an FQDN requires that the name is in DNS), ... > >And, perhaps this discussion will leave us where we were with=20 >no clear answer; but perhaps more details added to=20 >draft-ietf-dhc-option-guidelines to assist people in making a=20 >decision (I think Tomek indicated that he has an 09 pending=20 >with more to say on this matter). > >--- > >BTW: draft-boucadair-dhc-address-name-encoding-02 isn't that=20 >bad as it proposes using strings acceptable to getaddrinfo.=20 >Though I am not sure that these strings are that tightly=20 >specified.=20 Med: If the WG accepts this draft, we can work better the validation proced= ure to avoid errors which may be generated by blindly passing a string to a= name resolution library (e.g., what to do with IPv4-mapped IPv6 addresses,= if we allow the use of the bracket or not, trailing dot mandatory or optio= nal, etc.)=20 And, there are still cases where an IP address=20 >would be required (4-byte or 16-byte option data) - as a DNS=20 >resolver might not be available (if bootstrap loader, etc.) or=20 >result in a catch-22 (DNS server's list). And others where a=20 >FQDN is required. Med: One clarification here, draft-boucadair-dhc-address-name-encoding does= not propose to generate this format but it focuses only on the following c= ase (see Section 3): For contexts where both an IP Address and a FQDN should be supported in DHCP, it is RECOMMENDED to define one single option which is characterized as follows: This means: (1) if option designers think only an IP address is needed, then the format= should be designed as an IP-Address (2) if option designers think only an FQDN is needed, then the format shoul= d be designed to convey only FQDN (3) if option designers think only both an IP address and FQDN are needed, = then adopt the format proposed in draft-boucadair-dhc-address-name-encoding= . draft-boucadair-dhc-address-name-encoding can be used also for (1) and (2) = but I prefer to restrict the scope to (3) only. From internet-drafts@ietf.org Thu Nov 29 04: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 769BA21F8A03; Thu, 29 Nov 2012 04:13:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.529 X-Spam-Level: X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.070, 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 UgGeaS23VDdo; Thu, 29 Nov 2012 04:13:15 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00D3721F89F3; Thu, 29 Nov 2012 04:13:15 -0800 (PST) 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.36 Message-ID: <20121129121314.23806.75684.idtracker@ietfa.amsl.com> Date: Thu, 29 Nov 2012 04:13:14 -0800 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-05.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 12:13:15 -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-05.txt Pages : 9 Date : 2012-11-29 Abstract: The DHCPv6 RADIUS option provides a mechanism to exchange authorization and identification information between relay agent and server. This mechanism is meant for 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 Network Access 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-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-dhcpv6-radius-opt-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From leaf.yeh.sdo@gmail.com Thu Nov 29 04: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 B593421F89EF for ; Thu, 29 Nov 2012 04:21:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.933 X-Spam-Level: X-Spam-Status: No, score=-1.933 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_RECV_IP_219128=1.666] 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 YrKaXN46euZu for ; Thu, 29 Nov 2012 04:21:29 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id BF4AA21F89EC for ; Thu, 29 Nov 2012 04:21:27 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id hz11so8345035pad.31 for ; Thu, 29 Nov 2012 04:21:27 -0800 (PST) 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=lr4vGWs0mLLW1yN3nOADUj7EX/PiTgh8MQhvwqckS8Q=; b=nPVftQd+TZnoFJrbuMvNcFTeOavuQkSIN54ySgGJ7BnDWYjBMjglr/0PcF0qU85T6h inAIeK/2rgbWvXlS3Mq/0H7EzOOXFDQkBm0hinawPS5e8sv7Jr3WwodZ0wjt9Q/FpfNz 9ze+DJ2cgHhIqshzfRtCoPF+qAyg/xSDNd2d2QvvVS5kt3RcgNTWcwTQxdX+b5GcOwcw wX6jpqKnutNDObLoXwhCa5HPA540cjASMKOmyk0tIphmO+v1l3rHI61a/CUR1UwYrp9D vrL1k3WdcslPn+/MdZscc6pj2Wu8XA5l4dZFYDJ+jTxm8EfiehbkJnfA9GgM/e1cETz5 Rtew== Received: by 10.66.76.98 with SMTP id j2mr61108784paw.65.1354191687548; Thu, 29 Nov 2012 04:21:27 -0800 (PST) Received: from lst9242355d22a ([219.133.128.229]) by mx.google.com with ESMTPS id bv6sm1008812pab.13.2012.11.29.04.21.16 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 29 Nov 2012 04:21:26 -0800 (PST) From: "Leaf Yeh" To: References: <20121129121314.23806.75684.idtracker@ietfa.amsl.com> In-Reply-To: <20121129121314.23806.75684.idtracker@ietfa.amsl.com> Date: Thu, 29 Nov 2012 20:21:02 +0800 Message-ID: <50b75346.665a420a.6df5.59d0@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: Ac3OKuuVd4p6K/sbTwGNlgEILlfJYAAACA2w Content-Language: zh-cn Cc: 'Ted Lemon' Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-05.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 12:21:33 -0000 Hi folks, Draft (OPTION_RADIUS) has been updated to ver.-05, which solved the editorial comments from Roberta Maglione and Bernie Volz on the ML of DHC. The updates can be found at http://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-dhcpv6-radius-opt-05 . The draft (OPTION_RADIUS) of ver.-05 got the following text changes from ver. -04: a. Change the text to be "Note: The definition of the RADIUS attribute's 'Length' field in section 5 of [RFC2865] includes the length of 'Type' and 'Length' fields." in section 4 ; b. Add the text of 'New RADIUS attributes may be added to this list after the IETF Expert Review RFC5226].' in section 4 ; c. Replace 'IETF Review' to be 'IETF Expert Review' in section 9 ; d. Replace 2x 'Should' to be 'SHOULD', and replace 4x 'may' to be 'MAY' in the text body; Has it been ready to submit to IESG? Best Regards, Leaf -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Thursday, November 29, 2012 8:13 PM To: i-d-announce@ietf.org Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-05.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : RADIUS Option for DHCPv6 Relay Agents on Broadband Access Server Author(s) : Leaf Y. Yeh Mohamed Boucadair Ted Lemon Filename : draft-ietf-dhc-dhcpv6-radius-opt-05.txt Pages : 9 Date : 2012-11-29 Abstract: The DHCPv6 RADIUS option provides a mechanism to exchange authorization and identification information between relay agent and server. This mechanism is meant for 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 Network Access 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-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-dhcpv6-radius-opt-05 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 Thu Nov 29 05:33: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 51C6021F89F0 for ; Thu, 29 Nov 2012 05:33:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.058 X-Spam-Level: X-Spam-Status: No, score=-10.058 tagged_above=-999 required=5 tests=[AWL=0.542, 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 YnaL0-QqCjKm for ; Thu, 29 Nov 2012 05:33:55 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 4E4E421F89EF for ; Thu, 29 Nov 2012 05:33:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4101; q=dns/txt; s=iport; t=1354196035; x=1355405635; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=QnEXNSPk5ia6Nc3jEknwO2yrA0kcMGc6wvjuvCIVgg8=; b=Fj5sZL4CcqLX4u/Cr6oV3x5BPLbbYV2Sv+LeyN6nNqU76at8NtCvyb2I 8esu9nKvsKAmwinn0mSrdnLtgFd83v2jYU+YywSxgz/FKfpKxTnjWqAa6 MXVPYKQvhxpbfNIoZmeROQ4GSa0q2jJq2QLQDA+UO4D7MGbTZH2iPDARt g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwLAOljt1CtJV2d/2dsb2JhbABEwBgWbAeCHgEBAQMBeQULAgEIPwcyFBECBA4FiAoGvymMQAuDVWEDiCmNWJBEgnKBZQcXBg X-IronPort-AV: E=McAfee;i="5400,1158,6910"; a="144534577" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP; 29 Nov 2012 13:33:54 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id qATDXscq010543 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 29 Nov 2012 13:33:54 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.203]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.001; Thu, 29 Nov 2012 07:33:54 -0600 From: "Bernie Volz (volz)" To: "mohamed.boucadair@orange.com" Thread-Topic: [dhcwg] IP address vs. FQDN discussion Thread-Index: Ac3ES5usC9GRuubMQsaiLqHZGN/nqAB3HovAAOOVSQAABN1xAACU+/iAAAAhFYAAAIRSgAAk7QCAAEHyi8AAEbBBcAAM4dg2 Date: Thu, 29 Nov 2012 13:33:54 +0000 Message-ID: References: <94C682931C08B048B7A8645303FDC9F36E947B0E73@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E95C9F87B@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E9751E53D@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630747410569@mbx-01.win.nominum.com> <706C6EB5-3833-46B8-B79F-B8A4340669CE@cisco.com> <50B38CE3.5060806@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B6307474137AE@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36E98722CE4@PUEXCB1B.nanterre.francetelecom.fr> <489D13FBFA9B3E41812EA89F188F018E0F5AC6FA@xmb-rcd-x04.cisco.com>, <94C682931C08B048B7A8645303FDC9F36E98AB155A@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E98AB155A@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , Ted Lemon Subject: Re: [dhcwg] IP address vs. FQDN discussion X-BeenThere: dhcwg@ietf.org 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, 29 Nov 2012 13:33:56 -0000 I'd like to see the draft specially recommend to use either an address or f= qdn if at all possible (hence not use the draft) and only use this option f= ormat if there is a "hard" requirement for both. I haven't tried it but I don't think getaddrinfo allows brackets around v6 = addresses? Or are there some implementations that do?=20 Sent from my iPad On Nov 29, 2012, at 2:40 AM, "mohamed.boucadair@orange.com" wrote: > Dear Benrie, >=20 > Please see inline.=20 >=20 > Cheers, > Med >=20 >=20 >> -----Message d'origine----- >> De : Bernie Volz (volz) [mailto:volz@cisco.com]=20 >> Envoy=E9 : jeudi 29 novembre 2012 00:30 >> =C0 : BOUCADAIR Mohamed OLNC/OLN; Ted Lemon >> Cc : >> Objet : RE: [dhcwg] IP address vs. FQDN discussion >>=20 >> I think there was some discussion that I may have been the=20 >> cause of all of this? I don't recall the particular email or=20 >> discussion that might have triggered this, but I do recall=20 >> several drafts proposing to use two options (or sub-options) -=20 >> one for carrying the IPv4 address and another an FQDN - for a=20 >> particular configuration parameter. I also recall some other=20 >> drafts proposing a type enumerator followed by the data (based=20 >> on the type enumerator). And, I do recall suggesting that the=20 >> DHC WG perhaps take this issue up to provide some guidance as=20 >> to what is the best practice (perhaps in the Options Guideline=20 >> document). Personally, I do not like the idea of two options=20 >> (or sub-options) and an enumeration type followed by=20 >> appropriate data seems less desirable over picking one and=20 >> living with it. >>=20 >> As already covered in the discussion, the problem is also not=20 >> that simple because there are many considerations - who will=20 >> use the information, how soon will it be used, who can manage=20 >> the information (using an FQDN requires that the name is in DNS), ... >>=20 >> And, perhaps this discussion will leave us where we were with=20 >> no clear answer; but perhaps more details added to=20 >> draft-ietf-dhc-option-guidelines to assist people in making a=20 >> decision (I think Tomek indicated that he has an 09 pending=20 >> with more to say on this matter). >>=20 >> --- >>=20 >> BTW: draft-boucadair-dhc-address-name-encoding-02 isn't that=20 >> bad as it proposes using strings acceptable to getaddrinfo.=20 >> Though I am not sure that these strings are that tightly=20 >> specified. >=20 > Med: If the WG accepts this draft, we can work better the validation proc= edure to avoid errors which may be generated by blindly passing a string to= a name resolution library (e.g., what to do with IPv4-mapped IPv6 addresse= s, if we allow the use of the bracket or not, trailing dot mandatory or opt= ional, etc.)=20 >=20 >=20 > And, there are still cases where an IP address=20 >> would be required (4-byte or 16-byte option data) - as a DNS=20 >> resolver might not be available (if bootstrap loader, etc.) or=20 >> result in a catch-22 (DNS server's list). And others where a=20 >> FQDN is required. >=20 > Med: One clarification here, draft-boucadair-dhc-address-name-encoding do= es not propose to generate this format but it focuses only on the following= case (see Section 3): >=20 > For contexts where both an IP Address and a FQDN should be supported > in DHCP, it is RECOMMENDED to define one single option which is > characterized as follows: >=20 > This means: >=20 > (1) if option designers think only an IP address is needed, then the form= at should be designed as an IP-Address > (2) if option designers think only an FQDN is needed, then the format sho= uld be designed to convey only FQDN > (3) if option designers think only both an IP address and FQDN are needed= , then adopt the format proposed in draft-boucadair-dhc-address-name-encodi= ng. >=20 > draft-boucadair-dhc-address-name-encoding can be used also for (1) and (2= ) but I prefer to restrict the scope to (3) only. From mayer@ntp.org Thu Nov 29 05: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 0CC1D21F8A34 for ; Thu, 29 Nov 2012 05:58:06 -0800 (PST) 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 bp6IbC56HRLi for ; Thu, 29 Nov 2012 05:58:05 -0800 (PST) Received: from mx04.gis.net (mx04.gis.net [208.218.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id CBC8621F89B3 for ; Thu, 29 Nov 2012 05:58:04 -0800 (PST) Received: from [10.2.64.41] ([198.22.153.96]) by mx04.gis.net; Thu, 29 Nov 2012 08:57:48 -0500 Message-ID: <50B769DC.2080707@ntp.org> Date: Thu, 29 Nov 2012 08:57:48 -0500 From: Danny Mayer Organization: NTP User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "Bernie Volz (volz)" References: <94C682931C08B048B7A8645303FDC9F36E947B0E73@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E95C9F87B@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E9751E53D@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630747410569@mbx-01.win.nominum.com> <706C6EB5-3833-46B8-B79F-B8A4340669CE@cisco.com> <50B38CE3.5060806@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B6307474137AE@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36E98722CE4@PUEXCB1B.nanterre.francetelecom.fr> <489D13FBFA9B3E41812EA89F188F018E0F5AC6FA@xmb-rcd-x04.cisco.com>, <94C682931C08B048B7A8645303FDC9F36E98AB155A@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "" , Ted Lemon Subject: Re: [dhcwg] IP address vs. FQDN discussion X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mayer@ntp.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 13:58:06 -0000 There was already a discussion on this during the drafting of RFC5908. I wanted to make sure people didn't hardcode IP addresses in configuration options and instead allow them to be resolved via DNS so that NTP servers could be controlled better by the people who maintain them and so that they can change the host server whenever they wanted without needing to let everyone get involved. Danny On 11/29/2012 8:33 AM, Bernie Volz (volz) wrote: > I'd like to see the draft specially recommend to use either an address or fqdn if at all possible (hence not use the draft) and only use this option format if there is a "hard" requirement for both. > > I haven't tried it but I don't think getaddrinfo allows brackets around v6 addresses? Or are there some implementations that do? > > Sent from my iPad > > On Nov 29, 2012, at 2:40 AM, "mohamed.boucadair@orange.com" wrote: > >> Dear Benrie, >> >> Please see inline. >> >> Cheers, >> Med >> >> >>> -----Message d'origine----- >>> De : Bernie Volz (volz) [mailto:volz@cisco.com] >>> Envoyé : jeudi 29 novembre 2012 00:30 >>> À : BOUCADAIR Mohamed OLNC/OLN; Ted Lemon >>> Cc : >>> Objet : RE: [dhcwg] IP address vs. FQDN discussion >>> >>> I think there was some discussion that I may have been the >>> cause of all of this? I don't recall the particular email or >>> discussion that might have triggered this, but I do recall >>> several drafts proposing to use two options (or sub-options) - >>> one for carrying the IPv4 address and another an FQDN - for a >>> particular configuration parameter. I also recall some other >>> drafts proposing a type enumerator followed by the data (based >>> on the type enumerator). And, I do recall suggesting that the >>> DHC WG perhaps take this issue up to provide some guidance as >>> to what is the best practice (perhaps in the Options Guideline >>> document). Personally, I do not like the idea of two options >>> (or sub-options) and an enumeration type followed by >>> appropriate data seems less desirable over picking one and >>> living with it. >>> >>> As already covered in the discussion, the problem is also not >>> that simple because there are many considerations - who will >>> use the information, how soon will it be used, who can manage >>> the information (using an FQDN requires that the name is in DNS), ... >>> >>> And, perhaps this discussion will leave us where we were with >>> no clear answer; but perhaps more details added to >>> draft-ietf-dhc-option-guidelines to assist people in making a >>> decision (I think Tomek indicated that he has an 09 pending >>> with more to say on this matter). >>> >>> --- >>> >>> BTW: draft-boucadair-dhc-address-name-encoding-02 isn't that >>> bad as it proposes using strings acceptable to getaddrinfo. >>> Though I am not sure that these strings are that tightly >>> specified. >> >> Med: If the WG accepts this draft, we can work better the validation procedure to avoid errors which may be generated by blindly passing a string to a name resolution library (e.g., what to do with IPv4-mapped IPv6 addresses, if we allow the use of the bracket or not, trailing dot mandatory or optional, etc.) >> >> >> And, there are still cases where an IP address >>> would be required (4-byte or 16-byte option data) - as a DNS >>> resolver might not be available (if bootstrap loader, etc.) or >>> result in a catch-22 (DNS server's list). And others where a >>> FQDN is required. >> >> Med: One clarification here, draft-boucadair-dhc-address-name-encoding does not propose to generate this format but it focuses only on the following case (see Section 3): >> >> For contexts where both an IP Address and a FQDN should be supported >> in DHCP, it is RECOMMENDED to define one single option which is >> characterized as follows: >> >> This means: >> >> (1) if option designers think only an IP address is needed, then the format should be designed as an IP-Address >> (2) if option designers think only an FQDN is needed, then the format should be designed to convey only FQDN >> (3) if option designers think only both an IP address and FQDN are needed, then adopt the format proposed in draft-boucadair-dhc-address-name-encoding. >> >> draft-boucadair-dhc-address-name-encoding can be used also for (1) and (2) but I prefer to restrict the scope to (3) only. > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > From Ted.Lemon@nominum.com Thu Nov 29 07:37: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 4D2A021F8A8F for ; Thu, 29 Nov 2012 07:37:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kp5+L54TLifA for ; Thu, 29 Nov 2012 07:37:56 -0800 (PST) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id 6A94D21F8A8B for ; Thu, 29 Nov 2012 07:37:56 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKULeBU49MYdPfjPfd0gygKmhH61EZjFN5@postini.com; Thu, 29 Nov 2012 07:37:56 PST 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 4A6221B81A8 for ; Thu, 29 Nov 2012 07:37:55 -0800 (PST) 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 3BC20190052; Thu, 29 Nov 2012 07:37:55 -0800 (PST) (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.0318.004; Thu, 29 Nov 2012 07:37:49 -0800 From: Ted Lemon To: "mohamed.boucadair@orange.com" Thread-Topic: [dhcwg] IP address vs. FQDN discussion Thread-Index: Ac29xfcgXk0oSmncRrej4Wdd4AHprgFXckYAABhv9YAAQkoKgAB3S1WAANbWQAAABN2WgACU+9KAAAAhFYAAAIQGgAAUHP9QAGBwfoAAER2KgAAQrXuA Date: Thu, 29 Nov 2012 15:37:49 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63074741747B@mbx-01.win.nominum.com> References: <94C682931C08B048B7A8645303FDC9F36E947B0E73@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E95C9F87B@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E9751E53D@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630747410569@mbx-01.win.nominum.com> <706C6EB5-3833-46B8-B79F-B8A4340669CE@cisco.com> <50B38CE3.5060806@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B6307474137AE@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36E98722CE4@PUEXCB1B.nanterre.francetelecom.fr> <489D13FBFA9B3E41812EA89F188F018E0F5AC6FA@xmb-rcd-x04.cisco.com> <94C682931C08B048B7A8645303FDC9F36E98AB155A@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E98AB155A@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="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "Bernie Volz \(volz\)" Subject: Re: [dhcwg] IP address vs. FQDN discussion X-BeenThere: dhcwg@ietf.org 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, 29 Nov 2012 15:37:57 -0000 On Nov 29, 2012, at 2:40 AM, mohamed.boucadair@orange.com wrote: > (3) if option designers think only both an IP address and FQDN are needed= , then adopt the format proposed in draft-boucadair-dhc-address-name-encodi= ng. The problem I have with this is that most of the time when people say they = want both, they can't give a really good reason why they want both=97they j= ust want it. If you ask them for use cases, they can't come up with any. I would want the document to discourage the use of FQDNs, and to STRONGLY d= iscourage the use of a FQDN+IP address. In addition, any option that did use FQDN+IP address should be REQUIRED to = implement both FQDN and IP address. But I'm sure you see the problem with= this=97implementors often take MUST as advisory when it requires something= they don't want to have to code, like a DNS resolver. So if you have an = option that uses FQDN+IP, you can count on seeing serious interoperability = problems in the field. From mohamed.boucadair@orange.com Thu Nov 29 07:40: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 02AE421F8B1E for ; Thu, 29 Nov 2012 07:40:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.286 X-Spam-Level: X-Spam-Status: No, score=-2.286 tagged_above=-999 required=5 tests=[AWL=-0.038, 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 X9uuLbvK5QSO for ; Thu, 29 Nov 2012 07:40:22 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id CF40D21F8AC9 for ; Thu, 29 Nov 2012 07:40:21 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 2CA053B4358; Thu, 29 Nov 2012 16:40:16 +0100 (CET) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id ED618238056; Thu, 29 Nov 2012 16:40:15 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Thu, 29 Nov 2012 16:40:15 +0100 From: To: "Bernie Volz (volz)" Date: Thu, 29 Nov 2012 16:40:14 +0100 Thread-Topic: [dhcwg] IP address vs. FQDN discussion Thread-Index: Ac3ES5usC9GRuubMQsaiLqHZGN/nqAB3HovAAOOVSQAABN1xAACU+/iAAAAhFYAAAIRSgAAk7QCAAEHyi8AAEbBBcAAM4dg2AAQ/mDA= Message-ID: <94C682931C08B048B7A8645303FDC9F36E98AB1921@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E947B0E73@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E95C9F87B@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E9751E53D@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630747410569@mbx-01.win.nominum.com> <706C6EB5-3833-46B8-B79F-B8A4340669CE@cisco.com> <50B38CE3.5060806@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B6307474137AE@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36E98722CE4@PUEXCB1B.nanterre.francetelecom.fr> <489D13FBFA9B3E41812EA89F188F018E0F5AC6FA@xmb-rcd-x04.cisco.com>, <94C682931C08B048B7A8645303FDC9F36E98AB155A@PUEXCB1B.nanterre.francetelecom.fr> 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.10.24.110314 Cc: "" , Ted Lemon Subject: Re: [dhcwg] IP address vs. FQDN discussion X-BeenThere: dhcwg@ietf.org 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, 29 Nov 2012 15:40:23 -0000 Re-, Please see inline.=20 Cheers, Med=20 >-----Message d'origine----- >De : Bernie Volz (volz) [mailto:volz@cisco.com]=20 >Envoy=E9 : jeudi 29 novembre 2012 14:34 >=C0 : BOUCADAIR Mohamed OLNC/OLN >Cc : Ted Lemon; >Objet : Re: [dhcwg] IP address vs. FQDN discussion > >I'd like to see the draft specially recommend to use either an=20 >address or fqdn if at all possible (hence not use the draft)=20 >and only use this option format if there is a "hard"=20 >requirement for both. Med: I updated the text as follows: OLD: For contexts where both an IP Address and a FQDN should be supported in DHCP, it is RECOMMENDED to define one single option which is characterized as follows: NEW: Documents specifying future DHCP Options SHOULD motivate why an 'IP- Address'-only or FQDN-only encoding does not meet the expected requirements. For contexts where both an IP Address and a FQDN should be supported in DHCP, it is RECOMMENDED to define one single option which is characterized as follows: Are you fine with the new text?=20 > >I haven't tried it but I don't think getaddrinfo allows=20 >brackets around v6 addresses? Or are there some=20 >implementations that do?=20 Med: brackets are not allowed. The validation I'm talking about is what the= dhcp client need to do when it receives an IPv6 address with bracket: does= it reject the option or remove the bracket and pass it to the name resolut= ion library.=20 > >Sent from my iPad > >On Nov 29, 2012, at 2:40 AM, "mohamed.boucadair@orange.com"=20 > wrote: > >> Dear Benrie, >>=20 >> Please see inline.=20 >>=20 >> Cheers, >> Med >>=20 >>=20 >>> -----Message d'origine----- >>> De : Bernie Volz (volz) [mailto:volz@cisco.com]=20 >>> Envoy=E9 : jeudi 29 novembre 2012 00:30 >>> =C0 : BOUCADAIR Mohamed OLNC/OLN; Ted Lemon >>> Cc : >>> Objet : RE: [dhcwg] IP address vs. FQDN discussion >>>=20 >>> I think there was some discussion that I may have been the=20 >>> cause of all of this? I don't recall the particular email or=20 >>> discussion that might have triggered this, but I do recall=20 >>> several drafts proposing to use two options (or sub-options) -=20 >>> one for carrying the IPv4 address and another an FQDN - for a=20 >>> particular configuration parameter. I also recall some other=20 >>> drafts proposing a type enumerator followed by the data (based=20 >>> on the type enumerator). And, I do recall suggesting that the=20 >>> DHC WG perhaps take this issue up to provide some guidance as=20 >>> to what is the best practice (perhaps in the Options Guideline=20 >>> document). Personally, I do not like the idea of two options=20 >>> (or sub-options) and an enumeration type followed by=20 >>> appropriate data seems less desirable over picking one and=20 >>> living with it. >>>=20 >>> As already covered in the discussion, the problem is also not=20 >>> that simple because there are many considerations - who will=20 >>> use the information, how soon will it be used, who can manage=20 >>> the information (using an FQDN requires that the name is in=20 >DNS), ... >>>=20 >>> And, perhaps this discussion will leave us where we were with=20 >>> no clear answer; but perhaps more details added to=20 >>> draft-ietf-dhc-option-guidelines to assist people in making a=20 >>> decision (I think Tomek indicated that he has an 09 pending=20 >>> with more to say on this matter). >>>=20 >>> --- >>>=20 >>> BTW: draft-boucadair-dhc-address-name-encoding-02 isn't that=20 >>> bad as it proposes using strings acceptable to getaddrinfo.=20 >>> Though I am not sure that these strings are that tightly=20 >>> specified. >>=20 >> Med: If the WG accepts this draft, we can work better the=20 >validation procedure to avoid errors which may be generated by=20 >blindly passing a string to a name resolution library (e.g.,=20 >what to do with IPv4-mapped IPv6 addresses, if we allow the=20 >use of the bracket or not, trailing dot mandatory or optional, etc.)=20 >>=20 >>=20 >> And, there are still cases where an IP address=20 >>> would be required (4-byte or 16-byte option data) - as a DNS=20 >>> resolver might not be available (if bootstrap loader, etc.) or=20 >>> result in a catch-22 (DNS server's list). And others where a=20 >>> FQDN is required. >>=20 >> Med: One clarification here,=20 >draft-boucadair-dhc-address-name-encoding does not propose to=20 >generate this format but it focuses only on the following case=20 >(see Section 3): >>=20 >> For contexts where both an IP Address and a FQDN should be=20 >supported >> in DHCP, it is RECOMMENDED to define one single option which is >> characterized as follows: >>=20 >> This means: >>=20 >> (1) if option designers think only an IP address is needed,=20 >then the format should be designed as an IP-Address >> (2) if option designers think only an FQDN is needed, then=20 >the format should be designed to convey only FQDN >> (3) if option designers think only both an IP address and=20 >FQDN are needed, then adopt the format proposed in=20 >draft-boucadair-dhc-address-name-encoding. >>=20 >> draft-boucadair-dhc-address-name-encoding can be used also=20 >for (1) and (2) but I prefer to restrict the scope to (3) only. >= From Ted.Lemon@nominum.com Thu Nov 29 07:43: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 13BA421F8A88 for ; Thu, 29 Nov 2012 07:43:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.556 X-Spam-Level: X-Spam-Status: No, score=-106.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 Qsmp2vBei8Sm for ; Thu, 29 Nov 2012 07:43:22 -0800 (PST) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id 6B85321F8A95 for ; Thu, 29 Nov 2012 07:43:22 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKULeClSBJVKeipAfc2wudPWC4miQ+SsMA@postini.com; Thu, 29 Nov 2012 07:43:22 PST 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 8E1101B81C5 for ; Thu, 29 Nov 2012 07:43:16 -0800 (PST) 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 7CA23190052; Thu, 29 Nov 2012 07:43:16 -0800 (PST) (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.0318.004; Thu, 29 Nov 2012 07:43:16 -0800 From: Ted Lemon To: "" Thread-Topic: [dhcwg] IP address vs. FQDN discussion Thread-Index: Ac29xfcgXk0oSmncRrej4Wdd4AHprgFXckYAABhv9YAAQkoKgAB3S1WAANbWQAAABN2WgACU+9KAAAAhFYAAAIQGgAAUHP9QAGBwfoAAER2KgAAMWZQAAADVrwAAA67MgA== Date: Thu, 29 Nov 2012 15:43:15 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630747417511@mbx-01.win.nominum.com> References: <94C682931C08B048B7A8645303FDC9F36E947B0E73@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E95C9F87B@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E9751E53D@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630747410569@mbx-01.win.nominum.com> <706C6EB5-3833-46B8-B79F-B8A4340669CE@cisco.com> <50B38CE3.5060806@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B6307474137AE@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36E98722CE4@PUEXCB1B.nanterre.francetelecom.fr> <489D13FBFA9B3E41812EA89F188F018E0F5AC6FA@xmb-rcd-x04.cisco.com>, <94C682931C08B048B7A8645303FDC9F36E98AB155A@PUEXCB1B.nanterre.francetelecom.fr> <50B769DC.2080707@ntp.org> In-Reply-To: <50B769DC.2080707@ntp.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: "" , "Bernie Volz \(volz\)" Subject: Re: [dhcwg] IP address vs. FQDN discussion X-BeenThere: dhcwg@ietf.org 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, 29 Nov 2012 15:43:23 -0000 On Nov 29, 2012, at 8:57 AM, Danny Mayer wrote: > There was already a discussion on this during the drafting of RFC5908. I > wanted to make sure people didn't hardcode IP addresses in configuration > options and instead allow them to be resolved via DNS so that NTP > servers could be controlled better by the people who maintain them and > so that they can change the host server whenever they wanted without > needing to let everyone get involved. Yup. RFC5908 should never have been published=97it never went through las= t call in the DHC working group, and you did not take our advice on how the= option should work. Your successful effort to do what you want against t= he considered advice of the DHC working group is the example I give when I = talk about why we need to have expert review of all DHCP options on the way= through the IESG. From Ted.Lemon@nominum.com Thu Nov 29 07:53: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 57A0D21F8BA5 for ; Thu, 29 Nov 2012 07:53:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.566 X-Spam-Level: X-Spam-Status: No, score=-106.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 cyaji+F-Zfm1 for ; Thu, 29 Nov 2012 07:53:05 -0800 (PST) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB2921F87B6 for ; Thu, 29 Nov 2012 07:53:04 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKULeE30yMRCsLUv639mLeLEgrdtq90fer@postini.com; Thu, 29 Nov 2012 07:53:04 PST 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 9632E1B81B0 for ; Thu, 29 Nov 2012 07:53:02 -0800 (PST) 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 89ACF190052; Thu, 29 Nov 2012 07:53:02 -0800 (PST) (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.0318.004; Thu, 29 Nov 2012 07:53:02 -0800 From: Ted Lemon To: " " Thread-Topic: [dhcwg] IP address vs. FQDN discussion Thread-Index: Ac29xfcgXk0oSmncRrej4Wdd4AHprgFXckYAABhv9YAAQkoKgAB3S1WAANbWQAAABN2WgACU+9KAAAAhFYAAAIQGgAAUHP9QAGBwfoAAER2KgAAMWZQAAARpggAAAHJLgA== Date: Thu, 29 Nov 2012 15:53:02 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307474175B6@mbx-01.win.nominum.com> References: <94C682931C08B048B7A8645303FDC9F36E947B0E73@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E95C9F87B@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E9751E53D@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630747410569@mbx-01.win.nominum.com> <706C6EB5-3833-46B8-B79F-B8A4340669CE@cisco.com> <50B38CE3.5060806@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B6307474137AE@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36E98722CE4@PUEXCB1B.nanterre.francetelecom.fr> <489D13FBFA9B3E41812EA89F188F018E0F5AC6FA@xmb-rcd-x04.cisco.com>, <94C682931C08B048B7A8645303FDC9F36E98AB155A@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E98AB1921@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E98AB1921@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 Cc: "" , "Bernie Volz \(volz\)" Subject: Re: [dhcwg] IP address vs. FQDN discussion X-BeenThere: dhcwg@ietf.org 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, 29 Nov 2012 15:53:12 -0000 On Nov 29, 2012, at 10:40 AM, wrote: > Are you fine with the new text?=20 This is definitely better > Med: brackets are not allowed. The validation I'm talking about is what t= he dhcp client need to do when it receives an IPv6 address with bracket: do= es it reject the option or remove the bracket and pass it to the name resol= ution library.=20 I would add some text that reads like this: The DHCP agent decoding an option in this format MUST validate the contents= of the option. If the contents are not valid, the DHCP client MUST silen= tly ignore the option. The DHCP client MUST NOT attempt to process an inv= alid option of this type for reasons of compatibility with non-conforming i= mplementations, or for any other reason. To validate the option, the DHCP client verifies that none of the following= conditions are true: From mohamed.boucadair@orange.com Thu Nov 29 07:54:03 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 C797E21F8B67 for ; Thu, 29 Nov 2012 07:54:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.284 X-Spam-Level: X-Spam-Status: No, score=-2.284 tagged_above=-999 required=5 tests=[AWL=-0.036, 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 WcfMwRZaveoW for ; Thu, 29 Nov 2012 07:54:02 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id C902821F8AC2 for ; Thu, 29 Nov 2012 07:54:01 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 3614318C631; Thu, 29 Nov 2012 16:54:01 +0100 (CET) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 0E0454C015; Thu, 29 Nov 2012 16:54:01 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Thu, 29 Nov 2012 16:54:00 +0100 From: To: "mayer@ntp.org" , "Bernie Volz (volz)" Date: Thu, 29 Nov 2012 16:53:59 +0100 Thread-Topic: [dhcwg] IP address vs. FQDN discussion Thread-Index: Ac3OOYqz9jlRvcjLQSWx0rbfsh8U8QAD551w Message-ID: <94C682931C08B048B7A8645303FDC9F36E98AB1943@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E947B0E73@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E95C9F87B@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E9751E53D@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630747410569@mbx-01.win.nominum.com> <706C6EB5-3833-46B8-B79F-B8A4340669CE@cisco.com> <50B38CE3.5060806@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B6307474137AE@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36E98722CE4@PUEXCB1B.nanterre.francetelecom.fr> <489D13FBFA9B3E41812EA89F188F018E0F5AC6FA@xmb-rcd-x04.cisco.com>, <94C682931C08B048B7A8645303FDC9F36E98AB155A@PUEXCB1B.nanterre.francetelecom.fr> <50B769DC.2080707@ntp.org> In-Reply-To: <50B769DC.2080707@ntp.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.24.110314 Cc: "" , Ted Lemon Subject: Re: [dhcwg] IP address vs. FQDN discussion X-BeenThere: dhcwg@ietf.org 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, 29 Nov 2012 15:54:04 -0000 Dear Danny, I updated the draft with a new sub-section to list the argument you raised:= =20 =3D=3D=3D 2.2.4. Avoid Hard-coding IP Addresses Another reason to prefer using FQDNs rather than IP addresses is to avoid applications to hard-code IP addresses. Hard-coding the IP address(es) is seen as a hurdle to change the configuration of a service (server) in a transparent fashion. =3D=3D=3D Thanks. Cheers, Med=20 >-----Message d'origine----- >De : Danny Mayer [mailto:mayer@ntp.org]=20 >Envoy=E9 : jeudi 29 novembre 2012 14:58 >=C0 : Bernie Volz (volz) >Cc : BOUCADAIR Mohamed OLNC/OLN; ; Ted Lemon >Objet : Re: [dhcwg] IP address vs. FQDN discussion > >There was already a discussion on this during the drafting of=20 >RFC5908. I >wanted to make sure people didn't hardcode IP addresses in=20 >configuration >options and instead allow them to be resolved via DNS so that NTP >servers could be controlled better by the people who maintain them and >so that they can change the host server whenever they wanted without >needing to let everyone get involved. > >Danny > >On 11/29/2012 8:33 AM, Bernie Volz (volz) wrote: >> I'd like to see the draft specially recommend to use either=20 >an address or fqdn if at all possible (hence not use the=20 >draft) and only use this option format if there is a "hard"=20 >requirement for both. >>=20 >> I haven't tried it but I don't think getaddrinfo allows=20 >brackets around v6 addresses? Or are there some=20 >implementations that do?=20 >>=20 >> Sent from my iPad >>=20 >> On Nov 29, 2012, at 2:40 AM, "mohamed.boucadair@orange.com"=20 > wrote: >>=20 >>> Dear Benrie, >>> >>> Please see inline.=20 >>> >>> Cheers, >>> Med >>> >>> >>>> -----Message d'origine----- >>>> De : Bernie Volz (volz) [mailto:volz@cisco.com]=20 >>>> Envoy=E9 : jeudi 29 novembre 2012 00:30 >>>> =C0 : BOUCADAIR Mohamed OLNC/OLN; Ted Lemon >>>> Cc : >>>> Objet : RE: [dhcwg] IP address vs. FQDN discussion >>>> >>>> I think there was some discussion that I may have been the=20 >>>> cause of all of this? I don't recall the particular email or=20 >>>> discussion that might have triggered this, but I do recall=20 >>>> several drafts proposing to use two options (or sub-options) -=20 >>>> one for carrying the IPv4 address and another an FQDN - for a=20 >>>> particular configuration parameter. I also recall some other=20 >>>> drafts proposing a type enumerator followed by the data (based=20 >>>> on the type enumerator). And, I do recall suggesting that the=20 >>>> DHC WG perhaps take this issue up to provide some guidance as=20 >>>> to what is the best practice (perhaps in the Options Guideline=20 >>>> document). Personally, I do not like the idea of two options=20 >>>> (or sub-options) and an enumeration type followed by=20 >>>> appropriate data seems less desirable over picking one and=20 >>>> living with it. >>>> >>>> As already covered in the discussion, the problem is also not=20 >>>> that simple because there are many considerations - who will=20 >>>> use the information, how soon will it be used, who can manage=20 >>>> the information (using an FQDN requires that the name is=20 >in DNS), ... >>>> >>>> And, perhaps this discussion will leave us where we were with=20 >>>> no clear answer; but perhaps more details added to=20 >>>> draft-ietf-dhc-option-guidelines to assist people in making a=20 >>>> decision (I think Tomek indicated that he has an 09 pending=20 >>>> with more to say on this matter). >>>> >>>> --- >>>> >>>> BTW: draft-boucadair-dhc-address-name-encoding-02 isn't that=20 >>>> bad as it proposes using strings acceptable to getaddrinfo.=20 >>>> Though I am not sure that these strings are that tightly=20 >>>> specified. >>> >>> Med: If the WG accepts this draft, we can work better the=20 >validation procedure to avoid errors which may be generated by=20 >blindly passing a string to a name resolution library (e.g.,=20 >what to do with IPv4-mapped IPv6 addresses, if we allow the=20 >use of the bracket or not, trailing dot mandatory or optional, etc.)=20 >>> >>> >>> And, there are still cases where an IP address=20 >>>> would be required (4-byte or 16-byte option data) - as a DNS=20 >>>> resolver might not be available (if bootstrap loader, etc.) or=20 >>>> result in a catch-22 (DNS server's list). And others where a=20 >>>> FQDN is required. >>> >>> Med: One clarification here,=20 >draft-boucadair-dhc-address-name-encoding does not propose to=20 >generate this format but it focuses only on the following case=20 >(see Section 3): >>> >>> For contexts where both an IP Address and a FQDN should=20 >be supported >>> in DHCP, it is RECOMMENDED to define one single option which is >>> characterized as follows: >>> >>> This means: >>> >>> (1) if option designers think only an IP address is needed,=20 >then the format should be designed as an IP-Address >>> (2) if option designers think only an FQDN is needed, then=20 >the format should be designed to convey only FQDN >>> (3) if option designers think only both an IP address and=20 >FQDN are needed, then adopt the format proposed in=20 >draft-boucadair-dhc-address-name-encoding. >>> >>> draft-boucadair-dhc-address-name-encoding can be used also=20 >for (1) and (2) but I prefer to restrict the scope to (3) only. >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg >>=20 > >= From volz@cisco.com Thu Nov 29 08:00: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 312B521F8AA1 for ; Thu, 29 Nov 2012 08:00:36 -0800 (PST) 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 y0xd8pN2mdqK for ; Thu, 29 Nov 2012 08:00:35 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 0D0A521F85C0 for ; Thu, 29 Nov 2012 08:00:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6557; q=dns/txt; s=iport; t=1354204835; x=1355414435; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=e42P+HGdHclspfW+At2D181GoZlkgMi3kVC5zFYuAeI=; b=VTXMEbKRrXL+HGShRANTnT2HHLMUl/gA6X3dtmdir9AW9uSPkXVmRW0T T0oPHtEwKxmd3+SC3iQUFeNymThw5JXIasn6IhYwMTuogcHS2xIXP3Km4 KnkoSymZwdfZqgH5HmA09Iu1qGB0Ixf4hE7Cb7S/4i5STOj88vSNPW0Xl E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4LAI2Ft1CtJV2a/2dsb2JhbABEwBkWbAeCHgEBAQR5DAQCAQgRBAEBAQodBzIUCQgCBA4FCIgIvymMQAuDVWEDiCmeHIJygWUHFwYY X-IronPort-AV: E=McAfee;i="5400,1158,6910"; a="147589194" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 29 Nov 2012 16:00:34 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qATG0YuX023415 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 29 Nov 2012 16:00:34 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.203]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.001; Thu, 29 Nov 2012 10:00:34 -0600 From: "Bernie Volz (volz)" To: "mohamed.boucadair@orange.com" Thread-Topic: [dhcwg] IP address vs. FQDN discussion Thread-Index: Ac3ES5usC9GRuubMQsaiLqHZGN/nqAB3HovAAOOVSQAABN1xAACU+/iAAAAhFYAAAIRSgAAk7QCAAEHyi8AAEbBBcAAM4dg2AAQ/mDAAAIWFcA== Date: Thu, 29 Nov 2012 16:00:33 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E0F5BB935@xmb-rcd-x04.cisco.com> References: <94C682931C08B048B7A8645303FDC9F36E947B0E73@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E95C9F87B@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E9751E53D@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630747410569@mbx-01.win.nominum.com> <706C6EB5-3833-46B8-B79F-B8A4340669CE@cisco.com> <50B38CE3.5060806@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B6307474137AE@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36E98722CE4@PUEXCB1B.nanterre.francetelecom.fr> <489D13FBFA9B3E41812EA89F188F018E0F5AC6FA@xmb-rcd-x04.cisco.com>, <94C682931C08B048B7A8645303FDC9F36E98AB155A@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E98AB1921@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E98AB1921@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.245.109] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , Ted Lemon Subject: Re: [dhcwg] IP address vs. FQDN discussion X-BeenThere: dhcwg@ietf.org 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, 29 Nov 2012 16:00:36 -0000 Hi: I'd prefer to have the OLD/NEW text be revised to state that new options SH= OULD use either an address or FQDN encoding for the data and if there is a = strong requirement to support both that they MUST [SHOULD?] use this encodi= ng and provide the rational for why either an address or FQDN encoding is i= nsufficient. I don't think DHCP clients should be in the business of validating the synt= ax. Whatever uses the data should just call getaddrinfo and live with whate= ver it returns (after all, a valid FQDN may not resolve). This also extends= to checking for the trailing dot on an FQDN. Servers may want to provide validation, but I'm also inclined to recommend = against this -- if the administrator configures broken data, they will like= ly get a lot of support calls. (If the option contained an FQDN, would we e= xpect a server to validate that the FQDN is resolvable before giving it to = the client? I suspect not.) - Bernie -----Original Message----- From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com]=20 Sent: Thursday, November 29, 2012 10:40 AM To: Bernie Volz (volz) Cc: Ted Lemon; Subject: RE: [dhcwg] IP address vs. FQDN discussion Re-, Please see inline.=20 Cheers, Med=20 >-----Message d'origine----- >De : Bernie Volz (volz) [mailto:volz@cisco.com] Envoy=E9 : jeudi 29=20 >novembre 2012 14:34 =C0 : BOUCADAIR Mohamed OLNC/OLN Cc : Ted Lemon;=20 > Objet : Re: [dhcwg] IP address vs. FQDN discussion > >I'd like to see the draft specially recommend to use either an address=20 >or fqdn if at all possible (hence not use the draft) and only use this=20 >option format if there is a "hard" >requirement for both. Med: I updated the text as follows: OLD: For contexts where both an IP Address and a FQDN should be supported in DHCP, it is RECOMMENDED to define one single option which is characterized as follows: NEW: Documents specifying future DHCP Options SHOULD motivate why an 'IP- Address'-only or FQDN-only encoding does not meet the expected requirements. For contexts where both an IP Address and a FQDN should be supported in DHCP, it is RECOMMENDED to define one single option which is characterized as follows: Are you fine with the new text?=20 > >I haven't tried it but I don't think getaddrinfo allows brackets around=20 >v6 addresses? Or are there some implementations that do? Med: brackets are not allowed. The validation I'm talking about is what the= dhcp client need to do when it receives an IPv6 address with bracket: does= it reject the option or remove the bracket and pass it to the name resolut= ion library.=20 > >Sent from my iPad > >On Nov 29, 2012, at 2:40 AM, "mohamed.boucadair@orange.com"=20 > wrote: > >> Dear Benrie, >>=20 >> Please see inline.=20 >>=20 >> Cheers, >> Med >>=20 >>=20 >>> -----Message d'origine----- >>> De : Bernie Volz (volz) [mailto:volz@cisco.com] Envoy=E9 : jeudi 29=20 >>> novembre 2012 00:30 =C0 : BOUCADAIR Mohamed OLNC/OLN; Ted Lemon Cc :=20 >>> Objet : RE: [dhcwg] IP address vs. FQDN discussion >>>=20 >>> I think there was some discussion that I may have been the cause of=20 >>> all of this? I don't recall the particular email or discussion that=20 >>> might have triggered this, but I do recall several drafts proposing=20 >>> to use two options (or sub-options) - one for carrying the IPv4=20 >>> address and another an FQDN - for a particular configuration=20 >>> parameter. I also recall some other drafts proposing a type=20 >>> enumerator followed by the data (based on the type enumerator). And,=20 >>> I do recall suggesting that the DHC WG perhaps take this issue up to=20 >>> provide some guidance as to what is the best practice (perhaps in=20 >>> the Options Guideline document). Personally, I do not like the idea=20 >>> of two options (or sub-options) and an enumeration type followed by=20 >>> appropriate data seems less desirable over picking one and living=20 >>> with it. >>>=20 >>> As already covered in the discussion, the problem is also not that=20 >>> simple because there are many considerations - who will use the=20 >>> information, how soon will it be used, who can manage the=20 >>> information (using an FQDN requires that the name is in >DNS), ... >>>=20 >>> And, perhaps this discussion will leave us where we were with no=20 >>> clear answer; but perhaps more details added to=20 >>> draft-ietf-dhc-option-guidelines to assist people in making a=20 >>> decision (I think Tomek indicated that he has an 09 pending with=20 >>> more to say on this matter). >>>=20 >>> --- >>>=20 >>> BTW: draft-boucadair-dhc-address-name-encoding-02 isn't that bad as=20 >>> it proposes using strings acceptable to getaddrinfo. >>> Though I am not sure that these strings are that tightly specified. >>=20 >> Med: If the WG accepts this draft, we can work better the >validation procedure to avoid errors which may be generated by blindly=20 >passing a string to a name resolution library (e.g., what to do with=20 >IPv4-mapped IPv6 addresses, if we allow the use of the bracket or not,=20 >trailing dot mandatory or optional, etc.) >>=20 >>=20 >> And, there are still cases where an IP address >>> would be required (4-byte or 16-byte option data) - as a DNS=20 >>> resolver might not be available (if bootstrap loader, etc.) or=20 >>> result in a catch-22 (DNS server's list). And others where a FQDN is=20 >>> required. >>=20 >> Med: One clarification here, >draft-boucadair-dhc-address-name-encoding does not propose to generate=20 >this format but it focuses only on the following case (see Section 3): >>=20 >> For contexts where both an IP Address and a FQDN should be >supported >> in DHCP, it is RECOMMENDED to define one single option which is >> characterized as follows: >>=20 >> This means: >>=20 >> (1) if option designers think only an IP address is needed, >then the format should be designed as an IP-Address >> (2) if option designers think only an FQDN is needed, then >the format should be designed to convey only FQDN >> (3) if option designers think only both an IP address and >FQDN are needed, then adopt the format proposed in=20 >draft-boucadair-dhc-address-name-encoding. >>=20 >> draft-boucadair-dhc-address-name-encoding can be used also >for (1) and (2) but I prefer to restrict the scope to (3) only. > From volz@cisco.com Thu Nov 29 08:02: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 8DEE821F8AA1 for ; Thu, 29 Nov 2012 08:02:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.418 X-Spam-Level: X-Spam-Status: No, score=-10.418 tagged_above=-999 required=5 tests=[AWL=0.181, 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 gpM3P2vAgaT6 for ; Thu, 29 Nov 2012 08:02:28 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 738A121F8A9A for ; Thu, 29 Nov 2012 08:02:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1308; q=dns/txt; s=iport; t=1354204947; x=1355414547; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=WQcbDHfhlMinG+eGRDzkhvsFyOzjhFjsaCvGBvnKtPQ=; b=GFi/AvDvDhefQzyn0zayp3SGnLHlOYK0OyA0/Kz3727+UWqnRSuvzD61 8fCS8qLDXSu9gXQU/6X5b8QFQXPOzbS36MfM1B89tiIBD7yZx4zxOVdG0 94P36l+MzgQHjrM9sJOfnweVnSKLLzDxo2lz0nuKE+NZafEqp62W2D/N4 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAK2Gt1CtJXHB/2dsb2JhbABEwBkWc4IeAQEBAwE6PwUHBAIBCBEEAQEBChQJBzIUCQgCBAENBQiIAga/JYxAg2BhA6ZFgnKBZSQY X-IronPort-AV: E=McAfee;i="5400,1158,6910"; a="147590163" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-7.cisco.com with ESMTP; 29 Nov 2012 16:02:27 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id qATG2Rpr018930 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 29 Nov 2012 16:02:27 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.203]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.001; Thu, 29 Nov 2012 10:02:26 -0600 From: "Bernie Volz (volz)" To: Ted Lemon , " " Thread-Topic: [dhcwg] IP address vs. FQDN discussion Thread-Index: Ac3ES5usC9GRuubMQsaiLqHZGN/nqAB3HovAAOOVSQAABN1xAACU+/iAAAAhFYAAAIRSgAAk7QCAAEHyi8AAEbBBcAAM4dg2AAQ/mDAADS8GAAAMSD4A Date: Thu, 29 Nov 2012 16:02:25 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E0F5BB96A@xmb-rcd-x04.cisco.com> References: <94C682931C08B048B7A8645303FDC9F36E947B0E73@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E95C9F87B@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E9751E53D@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630747410569@mbx-01.win.nominum.com> <706C6EB5-3833-46B8-B79F-B8A4340669CE@cisco.com> <50B38CE3.5060806@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B6307474137AE@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36E98722CE4@PUEXCB1B.nanterre.francetelecom.fr> <489D13FBFA9B3E41812EA89F188F018E0F5AC6FA@xmb-rcd-x04.cisco.com>, <94C682931C08B048B7A8645303FDC9F36E98AB155A@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E98AB1921@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B6307474175B6@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307474175B6@mbx-01.win.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.245.109] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [dhcwg] IP address vs. FQDN discussion X-BeenThere: dhcwg@ietf.org 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, 29 Nov 2012 16:02:30 -0000 Seems that Ted and I disagree on whether a client should validate the data.= Good luck indeed! - Bernie -----Original Message----- From: Ted Lemon [mailto:Ted.Lemon@nominum.com]=20 Sent: Thursday, November 29, 2012 10:53 AM To: =20 Cc: Bernie Volz (volz); Subject: Re: [dhcwg] IP address vs. FQDN discussion On Nov 29, 2012, at 10:40 AM, wrote: > Are you fine with the new text?=20 This is definitely better > Med: brackets are not allowed. The validation I'm talking about is what t= he dhcp client need to do when it receives an IPv6 address with bracket: do= es it reject the option or remove the bracket and pass it to the name resol= ution library.=20 I would add some text that reads like this: The DHCP agent decoding an option in this format MUST validate the contents= of the option. If the contents are not valid, the DHCP client MUST silen= tly ignore the option. The DHCP client MUST NOT attempt to process an inv= alid option of this type for reasons of compatibility with non-conforming i= mplementations, or for any other reason. To validate the option, the DHCP client verifies that none of the following= conditions are true: From mohamed.boucadair@orange.com Thu Nov 29 08: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 468FF21F8469 for ; Thu, 29 Nov 2012 08:12:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.281 X-Spam-Level: X-Spam-Status: No, score=-2.281 tagged_above=-999 required=5 tests=[AWL=-0.033, 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 S2YtaumiRFog for ; Thu, 29 Nov 2012 08:12:31 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 695B821F8468 for ; Thu, 29 Nov 2012 08:12:31 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 6AD5218C8FF; Thu, 29 Nov 2012 17:12:23 +0100 (CET) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 4770D35C048; Thu, 29 Nov 2012 17:12:23 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Thu, 29 Nov 2012 17:12:23 +0100 From: To: Ted Lemon Date: Thu, 29 Nov 2012 17:12:21 +0100 Thread-Topic: [dhcwg] IP address vs. FQDN discussion Thread-Index: Ac29xfcgXk0oSmncRrej4Wdd4AHprgFXckYAABhv9YAAQkoKgAB3S1WAANbWQAAABN2WgACU+9KAAAAhFYAAAIQGgAAUHP9QAGBwfoAAER2KgAAMWZQAAARpggAAAHJLgAAQXfMQ Message-ID: <94C682931C08B048B7A8645303FDC9F36E98AB1971@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E947B0E73@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E95C9F87B@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E9751E53D@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630747410569@mbx-01.win.nominum.com> <706C6EB5-3833-46B8-B79F-B8A4340669CE@cisco.com> <50B38CE3.5060806@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B6307474137AE@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36E98722CE4@PUEXCB1B.nanterre.francetelecom.fr> <489D13FBFA9B3E41812EA89F188F018E0F5AC6FA@xmb-rcd-x04.cisco.com>, <94C682931C08B048B7A8645303FDC9F36E98AB155A@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E98AB1921@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B6307474175B6@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307474175B6@mbx-01.win.nominum.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.10.24.110314 Cc: "" , "Bernie Volz \(volz\)" Subject: Re: [dhcwg] IP address vs. FQDN discussion X-BeenThere: dhcwg@ietf.org 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, 29 Nov 2012 16:12:32 -0000 Re-, Please see inline.=20 Cheers, Med=20 >-----Message d'origine----- >De : Ted Lemon [mailto:Ted.Lemon@nominum.com]=20 >Envoy=E9 : jeudi 29 novembre 2012 16:53 >=C0 : BOUCADAIR Mohamed OLNC/OLN >Cc : Bernie Volz (volz); >Objet : Re: [dhcwg] IP address vs. FQDN discussion > >On Nov 29, 2012, at 10:40 AM, > wrote: >> Are you fine with the new text?=20 > >This is definitely better Med: Thanks. > >> Med: brackets are not allowed. The validation I'm talking=20 >about is what the dhcp client need to do when it receives an=20 >IPv6 address with bracket: does it reject the option or remove=20 >the bracket and pass it to the name resolution library.=20 > >I would add some text that reads like this: > >The DHCP agent decoding an option in this format MUST validate=20 >the contents of the option. If the contents are not valid,=20 >the DHCP client MUST silently ignore the option. The DHCP=20 >client MUST NOT attempt to process an invalid option of this=20 >type for reasons of compatibility with non-conforming=20 >implementations, or for any other reason. Med: I'm fine to add the text you proposed. I propose also to add the follo= wing: "A Name is considered as valid if it is a legitimate UTF-8 string which doe= s not contain any spaces nor nulls." Is this OK with you?=20 > >To validate the option, the DHCP client verifies that none of=20 >the following conditions are true: > > > >= From mohamed.boucadair@orange.com Thu Nov 29 08:14: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 5E2F521F8BE6 for ; Thu, 29 Nov 2012 08:14:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.279 X-Spam-Level: X-Spam-Status: No, score=-2.279 tagged_above=-999 required=5 tests=[AWL=-0.031, 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 3tSM77o+zOQe for ; Thu, 29 Nov 2012 08:14:16 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 8D81D21F8BCD for ; Thu, 29 Nov 2012 08:14:16 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 737A32645E3; Thu, 29 Nov 2012 17:14:15 +0100 (CET) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 448E235C05B; Thu, 29 Nov 2012 17:14:15 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Thu, 29 Nov 2012 17:14:15 +0100 From: To: Ted Lemon Date: Thu, 29 Nov 2012 17:14:13 +0100 Thread-Topic: [dhcwg] IP address vs. FQDN discussion Thread-Index: Ac29xfcgXk0oSmncRrej4Wdd4AHprgFXckYAABhv9YAAQkoKgAB3S1WAANbWQAAABN2WgACU+9KAAAAhFYAAAIQGgAAUHP9QAGBwfoAAER2KgAAMWZQAAADVrwAABA7CgAAAN+IAABBV2YA= Message-ID: <94C682931C08B048B7A8645303FDC9F36E98AB1974@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E947B0E73@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E95C9F87B@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E9751E53D@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630747410569@mbx-01.win.nominum.com> <706C6EB5-3833-46B8-B79F-B8A4340669CE@cisco.com> <50B38CE3.5060806@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B6307474137AE@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36E98722CE4@PUEXCB1B.nanterre.francetelecom.fr> <489D13FBFA9B3E41812EA89F188F018E0F5AC6FA@xmb-rcd-x04.cisco.com>, <94C682931C08B048B7A8645303FDC9F36E98AB155A@PUEXCB1B.nanterre.francetelecom.fr> <50B769DC.2080707@ntp.org> <94C682931C08B048B7A8645303FDC9F36E98AB1943@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B63074741760C@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63074741760C@mbx-01.win.nominum.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.11.29.151215 Cc: "Bernie Volz \(volz\)" , "" Subject: Re: [dhcwg] IP address vs. FQDN discussion X-BeenThere: dhcwg@ietf.org 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, 29 Nov 2012 16:14:17 -0000 Re-, IMO, the argument raised by D. Mayer makes sense. It is worth documenting i= t.=20 If you think any further clarification is needed to be added to the newly-a= dded sub-section, I will be happy to integrate it into the draft. Thanks. Cheers, Med >-----Message d'origine----- >De : Ted Lemon [mailto:Ted.Lemon@nominum.com]=20 >Envoy=E9 : jeudi 29 novembre 2012 17:00 >=C0 : BOUCADAIR Mohamed OLNC/OLN >Cc : mayer@ntp.org; Bernie Volz (volz); >Objet : Re: [dhcwg] IP address vs. FQDN discussion > >On Nov 29, 2012, at 10:53 AM, > wrote: >> Another reason to prefer using FQDNs rather than IP addresses is to >> avoid applications to hard-code IP addresses. Hard-coding the IP >> address(es) is seen as a hurdle to change the configuration of a >> service (server) in a transparent fashion. > >The scenario Danny was concerned about is the situation where=20 >an IP address is hard-coded into a home gateway (a real=20 >problem!). Unfortunately, using an FQDN doesn't help with=20 >this problem, since the problem is that the home gateway=20 >vendor didn't use DHCP in the first place to discover an NTP server. > >Problems of this sort are better resolved by BBF or Cablelabs=20 >requirements docs. > >= From Ted.Lemon@nominum.com Thu Nov 29 08:14: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 60D8221F8BE9 for ; Thu, 29 Nov 2012 08:14:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.569 X-Spam-Level: X-Spam-Status: No, score=-106.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 CB3FHMRFpZMy for ; Thu, 29 Nov 2012 08:14:16 -0800 (PST) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id E165D21F8BB5 for ; Thu, 29 Nov 2012 08:14:15 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKULeJ13FkFWbTvKZ0CUZEglBPE7R5ocT+@postini.com; Thu, 29 Nov 2012 08:14:15 PST 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 1B1A51B81B0 for ; Thu, 29 Nov 2012 08:14:15 -0800 (PST) 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 124A4190052; Thu, 29 Nov 2012 08:14:15 -0800 (PST) (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.0318.004; Thu, 29 Nov 2012 08:14:15 -0800 From: Ted Lemon To: "Bernie Volz (volz)" Thread-Topic: [dhcwg] IP address vs. FQDN discussion Thread-Index: Ac29xfcgXk0oSmncRrej4Wdd4AHprgFXckYAABhv9YAAQkoKgAB3S1WAANbWQAAABN2WgACU+9KAAAAhFYAAAIQGgAAUHP9QAGBwfoAAER2KgAAMWZQAAARpggAAALWlgAAAejGA Date: Thu, 29 Nov 2012 16:14:14 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63074741768B@mbx-01.win.nominum.com> References: <94C682931C08B048B7A8645303FDC9F36E947B0E73@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E95C9F87B@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E9751E53D@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630747410569@mbx-01.win.nominum.com> <706C6EB5-3833-46B8-B79F-B8A4340669CE@cisco.com> <50B38CE3.5060806@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B6307474137AE@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36E98722CE4@PUEXCB1B.nanterre.francetelecom.fr> <489D13FBFA9B3E41812EA89F188F018E0F5AC6FA@xmb-rcd-x04.cisco.com>, <94C682931C08B048B7A8645303FDC9F36E98AB155A@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E98AB1921@PUEXCB1B.nanterre.francetelecom.fr> <489D13FBFA9B3E41812EA89F188F018E0F5BB935@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E0F5BB935@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="Windows-1252" Content-ID: <5473D9FEA3D7304A94B405DB883479C0@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [dhcwg] IP address vs. FQDN discussion X-BeenThere: dhcwg@ietf.org 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, 29 Nov 2012 16:14:17 -0000 On Nov 29, 2012, at 11:00 AM, Bernie Volz (volz) wrote: > I don't think DHCP clients should be in the business of validating the sy= ntax. Whatever uses the data should just call getaddrinfo and live with wha= tever it returns (after all, a valid FQDN may not resolve). This also exten= ds to checking for the trailing dot on an FQDN. This is how bad exploitable bugs happen. If the client isn't responsible = for validation, and we can't hold the library accountable (we definitely ca= n't!), then no piece of code is accountable. And then you have an attack = surface. Maybe nothing bad will happen, but why take the chance when we c= an specify that the client does the validation? > Servers may want to provide validation, but I'm also inclined to recommen= d against this -- if the administrator configures broken data, they will li= kely get a lot of support calls. (If the option contained an FQDN, would we= expect a server to validate that the FQDN is resolvable before giving it t= o the client? I suspect not.) Validation on the server is a non-issue=97my concern at least is that this = provides an attack vector, not that it might be accidentally misconfigured.= As you say, that problem will take care of itself. From Ted.Lemon@nominum.com Thu Nov 29 08:21:03 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 4CE5A21F8469 for ; Thu, 29 Nov 2012 08:21:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.572 X-Spam-Level: X-Spam-Status: No, score=-106.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 83m5D5PXBDAG for ; Thu, 29 Nov 2012 08:21:02 -0800 (PST) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by ietfa.amsl.com (Postfix) with ESMTP id 8A7CC21F8442 for ; Thu, 29 Nov 2012 08:21:02 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKULeLbmbpzv3WrXURDjML9hFnV8U6jIb1@postini.com; Thu, 29 Nov 2012 08:21:02 PST 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 B1FD51B81B0 for ; Thu, 29 Nov 2012 08:21:01 -0800 (PST) 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 A873F190052; Thu, 29 Nov 2012 08:21:01 -0800 (PST) (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.0318.004; Thu, 29 Nov 2012 08:21:01 -0800 From: Ted Lemon To: "mohamed.boucadair@orange.com" Thread-Topic: [dhcwg] IP address vs. FQDN discussion Thread-Index: Ac29xfcgXk0oSmncRrej4Wdd4AHprgFXckYAABhv9YAAQkoKgAB3S1WAANbWQAAABN2WgACU+9KAAAAhFYAAAIQGgAAUHP9QAGBwfoAAER2KgAAMWZQAAARpggAAAHJLgAAQXfMQ//+E4QA= Date: Thu, 29 Nov 2012 16:21:01 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307474176DF@mbx-01.win.nominum.com> References: <94C682931C08B048B7A8645303FDC9F36E947B0E73@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E95C9F87B@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E9751E53D@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630747410569@mbx-01.win.nominum.com> <706C6EB5-3833-46B8-B79F-B8A4340669CE@cisco.com> <50B38CE3.5060806@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B6307474137AE@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36E98722CE4@PUEXCB1B.nanterre.francetelecom.fr> <489D13FBFA9B3E41812EA89F188F018E0F5AC6FA@xmb-rcd-x04.cisco.com>, <94C682931C08B048B7A8645303FDC9F36E98AB155A@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E98AB1921@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B6307474175B6@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36E98AB1971@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E98AB1971@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: <0B0790A0111CDD4D8C0E38E120D227FA@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "Bernie Volz \(volz\)" Subject: Re: [dhcwg] IP address vs. FQDN discussion X-BeenThere: dhcwg@ietf.org 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, 29 Nov 2012 16:21:03 -0000 On Nov 29, 2012, at 11:12 AM, mohamed.boucadair@orange.com wrote: > "A Name is considered as valid if it is a legitimate UTF-8 string which d= oes not contain any spaces nor nulls." No, the client needs to validate that it's either an IPv6 address or an FQD= N. The above test is certainly a good start, but it's not enough. From Ted.Lemon@nominum.com Thu Nov 29 08:23: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 CEAB321F8442 for ; Thu, 29 Nov 2012 08:23:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.574 X-Spam-Level: X-Spam-Status: No, score=-106.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 2i-6RDshhS45 for ; Thu, 29 Nov 2012 08:23:38 -0800 (PST) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id 7FBF521F8B81 for ; Thu, 29 Nov 2012 08:23:36 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKULeMCG0zuqsScOjhkunIsyHDTMpL6pcM@postini.com; Thu, 29 Nov 2012 08:23:36 PST 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 D8CF61B81A8 for ; Thu, 29 Nov 2012 08:23:35 -0800 (PST) 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 CFE5A190052; Thu, 29 Nov 2012 08:23:35 -0800 (PST) (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.0318.004; Thu, 29 Nov 2012 08:23:35 -0800 From: Ted Lemon To: "mohamed.boucadair@orange.com" Thread-Topic: [dhcwg] IP address vs. FQDN discussion Thread-Index: Ac29xfcgXk0oSmncRrej4Wdd4AHprgFXckYAABhv9YAAQkoKgAB3S1WAANbWQAAABN2WgACU+9KAAAAhFYAAAIQGgAAUHP9QAGBwfoAAER2KgAAMWZQAAADVrwAABA7CgAAAN+IAABBV2YD//4PWAA== Date: Thu, 29 Nov 2012 16:23:35 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63074741770F@mbx-01.win.nominum.com> References: <94C682931C08B048B7A8645303FDC9F36E947B0E73@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E95C9F87B@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E9751E53D@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630747410569@mbx-01.win.nominum.com> <706C6EB5-3833-46B8-B79F-B8A4340669CE@cisco.com> <50B38CE3.5060806@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B6307474137AE@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36E98722CE4@PUEXCB1B.nanterre.francetelecom.fr> <489D13FBFA9B3E41812EA89F188F018E0F5AC6FA@xmb-rcd-x04.cisco.com>, <94C682931C08B048B7A8645303FDC9F36E98AB155A@PUEXCB1B.nanterre.francetelecom.fr> <50B769DC.2080707@ntp.org> <94C682931C08B048B7A8645303FDC9F36E98AB1943@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B63074741760C@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36E98AB1974@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E98AB1974@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: <83A4B4BF510B284B9A5DBA22D720827C@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Bernie Volz \(volz\)" , "" Subject: Re: [dhcwg] IP address vs. FQDN discussion X-BeenThere: dhcwg@ietf.org 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, 29 Nov 2012 16:23:43 -0000 On Nov 29, 2012, at 11:14 AM, mohamed.boucadair@orange.com wrote: >>> Another reason to prefer using FQDNs rather than IP addresses is to >>> avoid applications to hard-code IP addresses. Hard-coding the IP >>> address(es) is seen as a hurdle to change the configuration of a >>> service (server) in a transparent fashion. The problem is that this text doesn't make any sense. If the DHCP server = sends an IP address, or if it sends an FQDN, it's not hard-coded. The only= case where it's hard-coded is when the application doesn't use DHCP at all= . So first of all, the person who needs to read this text isn't reading i= t, because they aren't doing DHCP. And secondly, the text is incorrect. From mohamed.boucadair@orange.com Thu Nov 29 08:26: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 971AC21F8508 for ; Thu, 29 Nov 2012 08:26:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.277 X-Spam-Level: X-Spam-Status: No, score=-2.277 tagged_above=-999 required=5 tests=[AWL=-0.029, 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 83iLo230NEjA for ; Thu, 29 Nov 2012 08:26:38 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id DACCF21F87FF for ; Thu, 29 Nov 2012 08:26:35 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 7F48422C550; Thu, 29 Nov 2012 17:26:31 +0100 (CET) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 62D214C015; Thu, 29 Nov 2012 17:26:31 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Thu, 29 Nov 2012 17:26:31 +0100 From: To: "Bernie Volz (volz)" Date: Thu, 29 Nov 2012 17:26:30 +0100 Thread-Topic: [dhcwg] IP address vs. FQDN discussion Thread-Index: Ac3ES5usC9GRuubMQsaiLqHZGN/nqAB3HovAAOOVSQAABN1xAACU+/iAAAAhFYAAAIRSgAAk7QCAAEHyi8AAEbBBcAAM4dg2AAQ/mDAAAIWFcAABO5Nw Message-ID: <94C682931C08B048B7A8645303FDC9F36E98AB1992@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E947B0E73@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E95C9F87B@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E9751E53D@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630747410569@mbx-01.win.nominum.com> <706C6EB5-3833-46B8-B79F-B8A4340669CE@cisco.com> <50B38CE3.5060806@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B6307474137AE@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36E98722CE4@PUEXCB1B.nanterre.francetelecom.fr> <489D13FBFA9B3E41812EA89F188F018E0F5AC6FA@xmb-rcd-x04.cisco.com>, <94C682931C08B048B7A8645303FDC9F36E98AB155A@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E98AB1921@PUEXCB1B.nanterre.francetelecom.fr> <489D13FBFA9B3E41812EA89F188F018E0F5BB935@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E0F5BB935@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.11.29.151215 Cc: "" , Ted Lemon Subject: Re: [dhcwg] IP address vs. FQDN discussion X-BeenThere: dhcwg@ietf.org 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, 29 Nov 2012 16:26:39 -0000 Re-, Here another text proposal: New DHCP options SHOULD use either an IP-Address or FQDN encoding for the data. If there is a strong requirement to support both an IP- Address and FQDN encoding, the option specification MUST use the encoding specified in this document and MUST provide the rationale to motivate why either an IP-Address or FQDN encoding is insufficient. Better? Cheers, Med=20 >-----Message d'origine----- >De : Bernie Volz (volz) [mailto:volz@cisco.com]=20 >Envoy=E9 : jeudi 29 novembre 2012 17:01 >=C0 : BOUCADAIR Mohamed OLNC/OLN >Cc : Ted Lemon; >Objet : RE: [dhcwg] IP address vs. FQDN discussion > >Hi: > >I'd prefer to have the OLD/NEW text be revised to state that=20 >new options SHOULD use either an address or FQDN encoding for=20 >the data and if there is a strong requirement to support both=20 >that they MUST [SHOULD?] use this encoding and provide the=20 >rational for why either an address or FQDN encoding is insufficient. > >I don't think DHCP clients should be in the business of=20 >validating the syntax. Whatever uses the data should just call=20 >getaddrinfo and live with whatever it returns (after all, a=20 >valid FQDN may not resolve). This also extends to checking for=20 >the trailing dot on an FQDN. > >Servers may want to provide validation, but I'm also inclined=20 >to recommend against this -- if the administrator configures=20 >broken data, they will likely get a lot of support calls. (If=20 >the option contained an FQDN, would we expect a server to=20 >validate that the FQDN is resolvable before giving it to the=20 >client? I suspect not.) > >- Bernie > >-----Original Message----- >From: mohamed.boucadair@orange.com=20 >[mailto:mohamed.boucadair@orange.com]=20 >Sent: Thursday, November 29, 2012 10:40 AM >To: Bernie Volz (volz) >Cc: Ted Lemon; >Subject: RE: [dhcwg] IP address vs. FQDN discussion > >Re-, > >Please see inline.=20 > >Cheers, >Med=20 > >>-----Message d'origine----- >>De : Bernie Volz (volz) [mailto:volz@cisco.com] Envoy=E9 : jeudi 29=20 >>novembre 2012 14:34 =C0 : BOUCADAIR Mohamed OLNC/OLN Cc : Ted Lemon;=20 >> Objet : Re: [dhcwg] IP address vs. FQDN discussion >> >>I'd like to see the draft specially recommend to use either=20 >an address=20 >>or fqdn if at all possible (hence not use the draft) and only=20 >use this=20 >>option format if there is a "hard" >>requirement for both. > >Med: I updated the text as follows: > >OLD: > > For contexts where both an IP Address and a FQDN should be supported > in DHCP, it is RECOMMENDED to define one single option which is > characterized as follows: > >NEW: > > Documents specifying future DHCP Options SHOULD motivate why an 'IP- > Address'-only or FQDN-only encoding does not meet the expected > requirements. > > For contexts where both an IP Address and a FQDN should be supported > in DHCP, it is RECOMMENDED to define one single option which is > characterized as follows: > >Are you fine with the new text?=20 > >> >>I haven't tried it but I don't think getaddrinfo allows=20 >brackets around=20 >>v6 addresses? Or are there some implementations that do? > >Med: brackets are not allowed. The validation I'm talking=20 >about is what the dhcp client need to do when it receives an=20 >IPv6 address with bracket: does it reject the option or remove=20 >the bracket and pass it to the name resolution library.=20 > >> >>Sent from my iPad >> >>On Nov 29, 2012, at 2:40 AM, "mohamed.boucadair@orange.com"=20 >> wrote: >> >>> Dear Benrie, >>>=20 >>> Please see inline.=20 >>>=20 >>> Cheers, >>> Med >>>=20 >>>=20 >>>> -----Message d'origine----- >>>> De : Bernie Volz (volz) [mailto:volz@cisco.com] Envoy=E9 : jeudi 29=20 >>>> novembre 2012 00:30 =C0 : BOUCADAIR Mohamed OLNC/OLN; Ted Lemon Cc :=20 >>>> Objet : RE: [dhcwg] IP address vs. FQDN discussion >>>>=20 >>>> I think there was some discussion that I may have been the=20 >cause of=20 >>>> all of this? I don't recall the particular email or=20 >discussion that=20 >>>> might have triggered this, but I do recall several drafts=20 >proposing=20 >>>> to use two options (or sub-options) - one for carrying the IPv4=20 >>>> address and another an FQDN - for a particular configuration=20 >>>> parameter. I also recall some other drafts proposing a type=20 >>>> enumerator followed by the data (based on the type=20 >enumerator). And,=20 >>>> I do recall suggesting that the DHC WG perhaps take this=20 >issue up to=20 >>>> provide some guidance as to what is the best practice (perhaps in=20 >>>> the Options Guideline document). Personally, I do not like=20 >the idea=20 >>>> of two options (or sub-options) and an enumeration type=20 >followed by=20 >>>> appropriate data seems less desirable over picking one and living=20 >>>> with it. >>>>=20 >>>> As already covered in the discussion, the problem is also not that=20 >>>> simple because there are many considerations - who will use the=20 >>>> information, how soon will it be used, who can manage the=20 >>>> information (using an FQDN requires that the name is in >>DNS), ... >>>>=20 >>>> And, perhaps this discussion will leave us where we were with no=20 >>>> clear answer; but perhaps more details added to=20 >>>> draft-ietf-dhc-option-guidelines to assist people in making a=20 >>>> decision (I think Tomek indicated that he has an 09 pending with=20 >>>> more to say on this matter). >>>>=20 >>>> --- >>>>=20 >>>> BTW: draft-boucadair-dhc-address-name-encoding-02 isn't=20 >that bad as=20 >>>> it proposes using strings acceptable to getaddrinfo. >>>> Though I am not sure that these strings are that tightly specified. >>>=20 >>> Med: If the WG accepts this draft, we can work better the >>validation procedure to avoid errors which may be generated=20 >by blindly=20 >>passing a string to a name resolution library (e.g., what to do with=20 >>IPv4-mapped IPv6 addresses, if we allow the use of the=20 >bracket or not,=20 >>trailing dot mandatory or optional, etc.) >>>=20 >>>=20 >>> And, there are still cases where an IP address >>>> would be required (4-byte or 16-byte option data) - as a DNS=20 >>>> resolver might not be available (if bootstrap loader, etc.) or=20 >>>> result in a catch-22 (DNS server's list). And others where=20 >a FQDN is=20 >>>> required. >>>=20 >>> Med: One clarification here, >>draft-boucadair-dhc-address-name-encoding does not propose to=20 >generate=20 >>this format but it focuses only on the following case (see Section 3): >>>=20 >>> For contexts where both an IP Address and a FQDN should be >>supported >>> in DHCP, it is RECOMMENDED to define one single option which is >>> characterized as follows: >>>=20 >>> This means: >>>=20 >>> (1) if option designers think only an IP address is needed, >>then the format should be designed as an IP-Address >>> (2) if option designers think only an FQDN is needed, then >>the format should be designed to convey only FQDN >>> (3) if option designers think only both an IP address and >>FQDN are needed, then adopt the format proposed in=20 >>draft-boucadair-dhc-address-name-encoding. >>>=20 >>> draft-boucadair-dhc-address-name-encoding can be used also >>for (1) and (2) but I prefer to restrict the scope to (3) only. >> >= From volz@cisco.com Thu Nov 29 08:28: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 640FD21F8616 for ; Thu, 29 Nov 2012 08:28:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.464 X-Spam-Level: X-Spam-Status: No, score=-10.464 tagged_above=-999 required=5 tests=[AWL=0.135, 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 onNp2D7Sdltv for ; Thu, 29 Nov 2012 08:28:36 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 6930C21F8A73 for ; Thu, 29 Nov 2012 08:28:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7684; q=dns/txt; s=iport; t=1354206516; x=1355416116; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=IiNr9NdncgZcQ/2qQnVTeunWQby/OsZNhOTt+SMKLHA=; b=Yu1AJ0nHb9o2iyVE+5cvJYbAwAFt8vOl5xJlXr2qQyw6WYzba3M5KpbK uxYRLN11TSMkd1L2vOqPyzMT4Y40hAROJHn9UxBjKJw7Ri3W5zth5EqaQ 9TNk1Zcym7rI+jDNp8zM8K77Bt6Zhx96X4YigXHeZJxC2zIZkwYnI4Y0t o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4LAPGLt1CtJV2b/2dsb2JhbABEwBkWbAeCHgEBAQR5DAQCAQgRBAEBAQodBzIUCQgCBA4FCIgIvyyMQAuDVWEDiCmeHIJygWUHFwYY X-IronPort-AV: E=McAfee;i="5400,1158,6910"; a="147600823" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 29 Nov 2012 16:28:35 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qATGSZmc010729 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 29 Nov 2012 16:28:35 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.203]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.001; Thu, 29 Nov 2012 10:28:35 -0600 From: "Bernie Volz (volz)" To: "mohamed.boucadair@orange.com" Thread-Topic: [dhcwg] IP address vs. FQDN discussion Thread-Index: Ac3ES5usC9GRuubMQsaiLqHZGN/nqAB3HovAAOOVSQAABN1xAACU+/iAAAAhFYAAAIRSgAAk7QCAAEHyi8AAEbBBcAAM4dg2AAQ/mDAAAIWFcAABO5NwAAAMJEA= Date: Thu, 29 Nov 2012 16:28:34 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E0F5BBB05@xmb-rcd-x04.cisco.com> References: <94C682931C08B048B7A8645303FDC9F36E947B0E73@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E95C9F87B@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E9751E53D@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630747410569@mbx-01.win.nominum.com> <706C6EB5-3833-46B8-B79F-B8A4340669CE@cisco.com> <50B38CE3.5060806@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B6307474137AE@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36E98722CE4@PUEXCB1B.nanterre.francetelecom.fr> <489D13FBFA9B3E41812EA89F188F018E0F5AC6FA@xmb-rcd-x04.cisco.com>, <94C682931C08B048B7A8645303FDC9F36E98AB155A@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E98AB1921@PUEXCB1B.nanterre.francetelecom.fr> <489D13FBFA9B3E41812EA89F188F018E0F5BB935@xmb-rcd-x04.cisco.com> <94C682931C08B048B7A8645303FDC9F36E98AB1992@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E98AB1992@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.245.251] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , Ted Lemon Subject: Re: [dhcwg] IP address vs. FQDN discussion X-BeenThere: dhcwg@ietf.org 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, 29 Nov 2012 16:28:37 -0000 Yes, I do like that much better. -----Original Message----- From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com]=20 Sent: Thursday, November 29, 2012 11:27 AM To: Bernie Volz (volz) Cc: Ted Lemon; Subject: RE: [dhcwg] IP address vs. FQDN discussion Re-, Here another text proposal: New DHCP options SHOULD use either an IP-Address or FQDN encoding for the data. If there is a strong requirement to support both an IP- Address and FQDN encoding, the option specification MUST use the encoding specified in this document and MUST provide the rationale to motivate why either an IP-Address or FQDN encoding is insufficient. Better? Cheers, Med=20 >-----Message d'origine----- >De : Bernie Volz (volz) [mailto:volz@cisco.com] Envoy=E9 : jeudi 29=20 >novembre 2012 17:01 =C0 : BOUCADAIR Mohamed OLNC/OLN Cc : Ted Lemon;=20 > Objet : RE: [dhcwg] IP address vs. FQDN discussion > >Hi: > >I'd prefer to have the OLD/NEW text be revised to state that new=20 >options SHOULD use either an address or FQDN encoding for the data and=20 >if there is a strong requirement to support both that they MUST=20 >[SHOULD?] use this encoding and provide the rational for why either an=20 >address or FQDN encoding is insufficient. > >I don't think DHCP clients should be in the business of validating the=20 >syntax. Whatever uses the data should just call getaddrinfo and live=20 >with whatever it returns (after all, a valid FQDN may not resolve).=20 >This also extends to checking for the trailing dot on an FQDN. > >Servers may want to provide validation, but I'm also inclined to=20 >recommend against this -- if the administrator configures broken data,=20 >they will likely get a lot of support calls. (If the option contained=20 >an FQDN, would we expect a server to validate that the FQDN is=20 >resolvable before giving it to the client? I suspect not.) > >- Bernie > >-----Original Message----- >From: mohamed.boucadair@orange.com >[mailto:mohamed.boucadair@orange.com] >Sent: Thursday, November 29, 2012 10:40 AM >To: Bernie Volz (volz) >Cc: Ted Lemon; >Subject: RE: [dhcwg] IP address vs. FQDN discussion > >Re-, > >Please see inline.=20 > >Cheers, >Med > >>-----Message d'origine----- >>De : Bernie Volz (volz) [mailto:volz@cisco.com] Envoy=E9 : jeudi 29=20 >>novembre 2012 14:34 =C0 : BOUCADAIR Mohamed OLNC/OLN Cc : Ted Lemon;=20 >> Objet : Re: [dhcwg] IP address vs. FQDN discussion >> >>I'd like to see the draft specially recommend to use either >an address >>or fqdn if at all possible (hence not use the draft) and only >use this >>option format if there is a "hard" >>requirement for both. > >Med: I updated the text as follows: > >OLD: > > For contexts where both an IP Address and a FQDN should be supported > in DHCP, it is RECOMMENDED to define one single option which is > characterized as follows: > >NEW: > > Documents specifying future DHCP Options SHOULD motivate why an 'IP- > Address'-only or FQDN-only encoding does not meet the expected > requirements. > > For contexts where both an IP Address and a FQDN should be supported > in DHCP, it is RECOMMENDED to define one single option which is > characterized as follows: > >Are you fine with the new text?=20 > >> >>I haven't tried it but I don't think getaddrinfo allows >brackets around >>v6 addresses? Or are there some implementations that do? > >Med: brackets are not allowed. The validation I'm talking about is what=20 >the dhcp client need to do when it receives an >IPv6 address with bracket: does it reject the option or remove the=20 >bracket and pass it to the name resolution library. > >> >>Sent from my iPad >> >>On Nov 29, 2012, at 2:40 AM, "mohamed.boucadair@orange.com"=20 >> wrote: >> >>> Dear Benrie, >>>=20 >>> Please see inline.=20 >>>=20 >>> Cheers, >>> Med >>>=20 >>>=20 >>>> -----Message d'origine----- >>>> De : Bernie Volz (volz) [mailto:volz@cisco.com] Envoy=E9 : jeudi 29=20 >>>> novembre 2012 00:30 =C0 : BOUCADAIR Mohamed OLNC/OLN; Ted Lemon Cc : >>>> Objet : RE: [dhcwg] IP address vs. FQDN discussion >>>>=20 >>>> I think there was some discussion that I may have been the >cause of >>>> all of this? I don't recall the particular email or >discussion that >>>> might have triggered this, but I do recall several drafts >proposing >>>> to use two options (or sub-options) - one for carrying the IPv4=20 >>>> address and another an FQDN - for a particular configuration=20 >>>> parameter. I also recall some other drafts proposing a type=20 >>>> enumerator followed by the data (based on the type >enumerator). And, >>>> I do recall suggesting that the DHC WG perhaps take this >issue up to >>>> provide some guidance as to what is the best practice (perhaps in=20 >>>> the Options Guideline document). Personally, I do not like >the idea >>>> of two options (or sub-options) and an enumeration type >followed by >>>> appropriate data seems less desirable over picking one and living=20 >>>> with it. >>>>=20 >>>> As already covered in the discussion, the problem is also not that=20 >>>> simple because there are many considerations - who will use the=20 >>>> information, how soon will it be used, who can manage the=20 >>>> information (using an FQDN requires that the name is in >>DNS), ... >>>>=20 >>>> And, perhaps this discussion will leave us where we were with no=20 >>>> clear answer; but perhaps more details added to=20 >>>> draft-ietf-dhc-option-guidelines to assist people in making a=20 >>>> decision (I think Tomek indicated that he has an 09 pending with=20 >>>> more to say on this matter). >>>>=20 >>>> --- >>>>=20 >>>> BTW: draft-boucadair-dhc-address-name-encoding-02 isn't >that bad as >>>> it proposes using strings acceptable to getaddrinfo. >>>> Though I am not sure that these strings are that tightly specified. >>>=20 >>> Med: If the WG accepts this draft, we can work better the >>validation procedure to avoid errors which may be generated >by blindly >>passing a string to a name resolution library (e.g., what to do with=20 >>IPv4-mapped IPv6 addresses, if we allow the use of the >bracket or not, >>trailing dot mandatory or optional, etc.) >>>=20 >>>=20 >>> And, there are still cases where an IP address >>>> would be required (4-byte or 16-byte option data) - as a DNS=20 >>>> resolver might not be available (if bootstrap loader, etc.) or=20 >>>> result in a catch-22 (DNS server's list). And others where >a FQDN is >>>> required. >>>=20 >>> Med: One clarification here, >>draft-boucadair-dhc-address-name-encoding does not propose to >generate >>this format but it focuses only on the following case (see Section 3): >>>=20 >>> For contexts where both an IP Address and a FQDN should be >>supported >>> in DHCP, it is RECOMMENDED to define one single option which is >>> characterized as follows: >>>=20 >>> This means: >>>=20 >>> (1) if option designers think only an IP address is needed, >>then the format should be designed as an IP-Address >>> (2) if option designers think only an FQDN is needed, then >>the format should be designed to convey only FQDN >>> (3) if option designers think only both an IP address and >>FQDN are needed, then adopt the format proposed in=20 >>draft-boucadair-dhc-address-name-encoding. >>>=20 >>> draft-boucadair-dhc-address-name-encoding can be used also >>for (1) and (2) but I prefer to restrict the scope to (3) only. >> > From volz@cisco.com Thu Nov 29 08:40: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 D696C21F89E1 for ; Thu, 29 Nov 2012 08:40:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4MlCvjkL6A73 for ; Thu, 29 Nov 2012 08:40:32 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 26C9721F89EE for ; Thu, 29 Nov 2012 08:40:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1382; q=dns/txt; s=iport; t=1354207232; x=1355416832; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=y0FiNDoNA47GMBe6srKwwHEiC6hwGscmhfL/dIy1EE0=; b=agSz6L9XCVwlcQuRnf1qWhY8ydOZ4L1qQ/htGIYGyy6iqPGxqCrQiebo bBrVhvlno3DPIT70wf4B8kMEoWMBIpL8GhT4qZxcpbKrRqlKbP7OIL3KG vSwh2kGHLnIor6A0f2jilRyxsdGR6/cOC013tPLqaQaJNdGNYLtZhbZCI Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAOWOt1CtJV2c/2dsb2JhbABEwBkWc4IeAQEBBDo/DAQCAQgRBAEBAQoUCQcyFAkIAgQBDQUIiAi/IoxAFYNLYQOmRYJygWMCHgYY X-IronPort-AV: E=McAfee;i="5400,1158,6910"; a="147607583" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP; 29 Nov 2012 16:40:31 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id qATGeVZ2015433 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 29 Nov 2012 16:40:31 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.203]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.001; Thu, 29 Nov 2012 10:40:31 -0600 From: "Bernie Volz (volz)" To: Ted Lemon , "mohamed.boucadair@orange.com" Thread-Topic: [dhcwg] IP address vs. FQDN discussion Thread-Index: Ac3ES5usC9GRuubMQsaiLqHZGN/nqAFXckYAABhv9YAAQkoKgAB3S1WAANbWQAAABN2WgACU+9KAAAAhFYAAAIQGgAAUHP9QAGBwfoAAER2KgAAMWZQAAARpggAAAHJLgAAQXfMQ//JYEoCAAGJx4A== Date: Thu, 29 Nov 2012 16:40:31 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E0F5BBB6A@xmb-rcd-x04.cisco.com> References: <94C682931C08B048B7A8645303FDC9F36E947B0E73@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E95C9F87B@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E9751E53D@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630747410569@mbx-01.win.nominum.com> <706C6EB5-3833-46B8-B79F-B8A4340669CE@cisco.com> <50B38CE3.5060806@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B6307474137AE@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36E98722CE4@PUEXCB1B.nanterre.francetelecom.fr> <489D13FBFA9B3E41812EA89F188F018E0F5AC6FA@xmb-rcd-x04.cisco.com>, <94C682931C08B048B7A8645303FDC9F36E98AB155A@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E98AB1921@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B6307474175B6@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36E98AB1971@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B6307474176DF@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307474176DF@mbx-01.win.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.245.251] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [dhcwg] IP address vs. FQDN discussion X-BeenThere: dhcwg@ietf.org 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, 29 Nov 2012 16:40:32 -0000 While I think the focus is on IPv6 (DHCPv6), I would hope that whatever we = end up with also extends to v4 if there are new options needed there. I'm still not convinced that validating (on the client side) is worth it. Are you afraid that if someone sends in some string that they can trick the= 'getaddrinfo' routine into doing something bad? Wouldn't other application= s then be subject to this and wouldn't it be better to fix 'getaddrinfo'? (I guess the one benefit of putting in some validation text is that the IES= G might be happier to see that? But, I wonder how much that will help as pr= obably the FQDN validation will provide minimal protection - as it requires= a dot at least after every 63 characters and there is a limited character = set.) - Bernie -----Original Message----- From: Ted Lemon [mailto:Ted.Lemon@nominum.com]=20 Sent: Thursday, November 29, 2012 11:21 AM To: mohamed.boucadair@orange.com Cc: Bernie Volz (volz); Subject: Re: [dhcwg] IP address vs. FQDN discussion On Nov 29, 2012, at 11:12 AM, mohamed.boucadair@orange.com wrote: > "A Name is considered as valid if it is a legitimate UTF-8 string which d= oes not contain any spaces nor nulls." No, the client needs to validate that it's either an IPv6 address or an FQD= N. The above test is certainly a good start, but it's not enough. From mayer@ntp.org Thu Nov 29 08: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 42F7721F8ED9 for ; Thu, 29 Nov 2012 08:51:30 -0800 (PST) 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 sxq2CY6kClMU for ; Thu, 29 Nov 2012 08:51:29 -0800 (PST) Received: from mail1.ntp.org (mail1.ntp.org [IPv6:2001:4f8:fff7:1::5]) by ietfa.amsl.com (Postfix) with ESMTP id C3C5921F8EA0 for ; Thu, 29 Nov 2012 08:51:29 -0800 (PST) Received: from [198.22.153.96] (helo=[10.2.64.41]) by mail1.ntp.org with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Te7Kf-00006z-Tr; Thu, 29 Nov 2012 16:51:27 +0000 Message-ID: <50B79286.7090000@ntp.org> Date: Thu, 29 Nov 2012 11:51:18 -0500 From: Danny Mayer User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Ted Lemon References: <94C682931C08B048B7A8645303FDC9F36E947B0E73@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E95C9F87B@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E9751E53D@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630747410569@mbx-01.win.nominum.com> <706C6EB5-3833-46B8-B79F-B8A4340669CE@cisco.com> <50B38CE3.5060806@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B6307474137AE@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36E98722CE4@PUEXCB1B.nanterre.francetelecom.fr> <489D13FBFA9B3E41812EA89F188F018E0F5AC6FA@xmb-rcd-x04.cisco.com>, <94C682931C08B048B7A8645303FDC9F36E98AB155A@PUEXCB1B.nanterre.francetelecom.fr> <50B769DC.2080707@ntp.org> <8D23D4052ABE7A4490E77B1A012B630747417511@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630747417511@mbx-01.win.nominum.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 198.22.153.96 X-SA-Exim-Rcpt-To: Ted.Lemon@nominum.com, volz@cisco.com, mohamed.boucadair@orange.com, dhcwg@ietf.org X-SA-Exim-Mail-From: mayer@ntp.org X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Cc: "" , "Bernie Volz \(volz\)" Subject: Re: [dhcwg] IP address vs. FQDN discussion X-BeenThere: dhcwg@ietf.org 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, 29 Nov 2012 16:51:30 -0000 On 11/29/2012 10:43 AM, Ted Lemon wrote: > On Nov 29, 2012, at 8:57 AM, Danny Mayer wrote: >> There was already a discussion on this during the drafting of RFC5908. I >> wanted to make sure people didn't hardcode IP addresses in configuration >> options and instead allow them to be resolved via DNS so that NTP >> servers could be controlled better by the people who maintain them and >> so that they can change the host server whenever they wanted without >> needing to let everyone get involved. > > Yup. RFC5908 should never have been published—it never went through last call in the DHC working group, and you did not take our advice on how the option should work. Your successful effort to do what you want against the considered advice of the DHC working group is the example I give when I talk about why we need to have expert review of all DHCP options on the way through the IESG. > > There were very good reasons for this. One reason for this for NTP was because we have had NTP server operators change the IP address of the server to be used and the old address continued to be hammered by clients who ignored the change. In addition we can now have DNS specify multiple addresses for the same FQSN and the NTP server being provisioned will then be able to be provisioned to use all of them. I don't know why the DHC WG wasn't doing expert review. Maybe a discussion with Ralph Droms would be useful? Danny From mohamed.boucadair@orange.com Thu Nov 29 09:01: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 30D6621F841D for ; Thu, 29 Nov 2012 09:01:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.276 X-Spam-Level: X-Spam-Status: No, score=-2.276 tagged_above=-999 required=5 tests=[AWL=-0.028, 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 yDmCwKLGLN7S for ; Thu, 29 Nov 2012 09:01:31 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id B5F0921F8680 for ; Thu, 29 Nov 2012 09:01:28 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id CAFFF3B417F; Thu, 29 Nov 2012 18:01:27 +0100 (CET) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id AF1F027C046; Thu, 29 Nov 2012 18:01:27 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Thu, 29 Nov 2012 18:01:27 +0100 From: To: Ted Lemon Date: Thu, 29 Nov 2012 18:01:26 +0100 Thread-Topic: [dhcwg] IP address vs. FQDN discussion Thread-Index: Ac29xfcgXk0oSmncRrej4Wdd4AHprgFXckYAABhv9YAAQkoKgAB3S1WAANbWQAAABN2WgACU+9KAAAAhFYAAAIQGgAAUHP9QAGBwfoAAER2KgAAMWZQAAARpggAAAHJLgAAQXfMQ//+E4QCAAHvR8A== Message-ID: <94C682931C08B048B7A8645303FDC9F36E98AB19CE@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E947B0E73@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E95C9F87B@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E9751E53D@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630747410569@mbx-01.win.nominum.com> <706C6EB5-3833-46B8-B79F-B8A4340669CE@cisco.com> <50B38CE3.5060806@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B6307474137AE@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36E98722CE4@PUEXCB1B.nanterre.francetelecom.fr> <489D13FBFA9B3E41812EA89F188F018E0F5AC6FA@xmb-rcd-x04.cisco.com>, <94C682931C08B048B7A8645303FDC9F36E98AB155A@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E98AB1921@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B6307474175B6@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36E98AB1971@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B6307474176DF@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307474176DF@mbx-01.win.nominum.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.11.29.164516 Cc: "" , "Bernie Volz \(volz\)" Subject: Re: [dhcwg] IP address vs. FQDN discussion X-BeenThere: dhcwg@ietf.org 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, 29 Nov 2012 17:01:32 -0000 Re-, Here is an updated text: o The DHCP client decoding an option in this format MUST validate the contents of the option. If the contents are not valid, the DHCP client MUST silently ignore the option. The DHCP client MUST NOT attempt to process an invalid option of this type for reasons of compatibility with non-conforming implementations, or for any other reason. A Name is considered as valid if: * It is a legal UTF-8 string which does not contain any spaces nor nulls. * It contains IPv4 address in dotted-decimal form (e.g., 192.0.2.33), textual representation of an IPv6 address (e.g., 2001:db8::1) [RFC2373] [RFC5952] or a domain name (e.g., "myservice.example.com"). Note: + The trailing dot is optional when a domain name is conveyed in the option. + IPv4-mapped IPv6 addresses (e.g., ::fff:192.0.2.33) are valid IPv6 addresses. + IPv6 addresses MUST NOT be enclosed in brackets. Cheers, Med =20 >-----Message d'origine----- >De : Ted Lemon [mailto:Ted.Lemon@nominum.com]=20 >Envoy=E9 : jeudi 29 novembre 2012 17:21 >=C0 : BOUCADAIR Mohamed OLNC/OLN >Cc : Bernie Volz (volz); >Objet : Re: [dhcwg] IP address vs. FQDN discussion > >On Nov 29, 2012, at 11:12 AM, mohamed.boucadair@orange.com wrote: >> "A Name is considered as valid if it is a legitimate UTF-8=20 >string which does not contain any spaces nor nulls." > >No, the client needs to validate that it's either an IPv6=20 >address or an FQDN. The above test is certainly a good=20 >start, but it's not enough. > >= From Ted.Lemon@nominum.com Thu Nov 29 09:10: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 2B6D321F8B24 for ; Thu, 29 Nov 2012 09:10:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.576 X-Spam-Level: X-Spam-Status: No, score=-106.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 VSZk3Jhc-5Tt for ; Thu, 29 Nov 2012 09:10:55 -0800 (PST) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by ietfa.amsl.com (Postfix) with ESMTP id 7971B21F8B23 for ; Thu, 29 Nov 2012 09:10:55 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKULeXH0zz+0h+ySxbw2xJ1ItCWGM10p+Y@postini.com; Thu, 29 Nov 2012 09:10:55 PST 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 8F3A51B81C5 for ; Thu, 29 Nov 2012 08:00:15 -0800 (PST) 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 80709190052; Thu, 29 Nov 2012 08:00:15 -0800 (PST) (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.0318.004; Thu, 29 Nov 2012 08:00:15 -0800 From: Ted Lemon To: " " Thread-Topic: [dhcwg] IP address vs. FQDN discussion Thread-Index: Ac29xfcgXk0oSmncRrej4Wdd4AHprgFXckYAABhv9YAAQkoKgAB3S1WAANbWQAAABN2WgACU+9KAAAAhFYAAAIQGgAAUHP9QAGBwfoAAER2KgAAMWZQAAADVrwAABA7CgAAAN+IA Date: Thu, 29 Nov 2012 16:00:15 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63074741760C@mbx-01.win.nominum.com> References: <94C682931C08B048B7A8645303FDC9F36E947B0E73@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E95C9F87B@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E9751E53D@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630747410569@mbx-01.win.nominum.com> <706C6EB5-3833-46B8-B79F-B8A4340669CE@cisco.com> <50B38CE3.5060806@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B6307474137AE@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36E98722CE4@PUEXCB1B.nanterre.francetelecom.fr> <489D13FBFA9B3E41812EA89F188F018E0F5AC6FA@xmb-rcd-x04.cisco.com>, <94C682931C08B048B7A8645303FDC9F36E98AB155A@PUEXCB1B.nanterre.francetelecom.fr> <50B769DC.2080707@ntp.org> <94C682931C08B048B7A8645303FDC9F36E98AB1943@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E98AB1943@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 Cc: "Bernie Volz \(volz\)" , "" Subject: Re: [dhcwg] IP address vs. FQDN discussion X-BeenThere: dhcwg@ietf.org 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, 29 Nov 2012 17:10:56 -0000 On Nov 29, 2012, at 10:53 AM, wrote: > Another reason to prefer using FQDNs rather than IP addresses is to > avoid applications to hard-code IP addresses. Hard-coding the IP > address(es) is seen as a hurdle to change the configuration of a > service (server) in a transparent fashion. The scenario Danny was concerned about is the situation where an IP address= is hard-coded into a home gateway (a real problem!). Unfortunately, usin= g an FQDN doesn't help with this problem, since the problem is that the hom= e gateway vendor didn't use DHCP in the first place to discover an NTP serv= er. Problems of this sort are better resolved by BBF or Cablelabs requirements = docs. From Ted.Lemon@nominum.com Thu Nov 29 09: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 178E821F8B27 for ; Thu, 29 Nov 2012 09:30:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.578 X-Spam-Level: X-Spam-Status: No, score=-106.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 z4gL8vRWCYVm for ; Thu, 29 Nov 2012 09:30:29 -0800 (PST) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id 2EB8121F8AC7 for ; Thu, 29 Nov 2012 09:30:29 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKULebtFPmS8kaLBv6/iPxLC4ncTNDtH5e@postini.com; Thu, 29 Nov 2012 09:30:29 PST 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 34D19F8003 for ; Thu, 29 Nov 2012 09:30:28 -0800 (PST) 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 2ABE7190052; Thu, 29 Nov 2012 09:30:28 -0800 (PST) (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.0318.004; Thu, 29 Nov 2012 09:30:28 -0800 From: Ted Lemon To: "Bernie Volz (volz)" Thread-Topic: [dhcwg] IP address vs. FQDN discussion Thread-Index: Ac29xfcgXk0oSmncRrej4Wdd4AHprgFXckYAABhv9YAAQkoKgAB3S1WAANbWQAAABN2WgACU+9KAAAAhFYAAAIQGgAAUHP9QAGBwfoAAER2KgAAMWZQAAARpggAAAHJLgAAQXfMQ//+E4QCAAAV0gIAADfMA Date: Thu, 29 Nov 2012 17:30:27 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630747417891@mbx-01.win.nominum.com> References: <94C682931C08B048B7A8645303FDC9F36E947B0E73@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E95C9F87B@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E9751E53D@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630747410569@mbx-01.win.nominum.com> <706C6EB5-3833-46B8-B79F-B8A4340669CE@cisco.com> <50B38CE3.5060806@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B6307474137AE@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36E98722CE4@PUEXCB1B.nanterre.francetelecom.fr> <489D13FBFA9B3E41812EA89F188F018E0F5AC6FA@xmb-rcd-x04.cisco.com>, <94C682931C08B048B7A8645303FDC9F36E98AB155A@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E98AB1921@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B6307474175B6@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36E98AB1971@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B6307474176DF@mbx-01.win.nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F5BBB6A@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E0F5BBB6A@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="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [dhcwg] IP address vs. FQDN discussion X-BeenThere: dhcwg@ietf.org 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, 29 Nov 2012 17:30:30 -0000 On Nov 29, 2012, at 11:40 AM, "Bernie Volz (volz)" wrote: > Are you afraid that if someone sends in some string that they can trick t= he 'getaddrinfo' routine into doing something bad? Wouldn't other applicati= ons then be subject to this and wouldn't it be better to fix 'getaddrinfo'? A better option, IMHO, would be to eliminate getaddrinfo, because it's a ba= d idea=97the code that takes user input should decide whether the user inpu= t is an IP address or an FQDN, and then call the appropriate function. Ha= ving a library function that gets unvalidated user data is broken, and if t= he user data has been validated, the validator knows whether it's an IP add= ress or an FQDN, so there's no need for a function that can handle both.=20 My concern is that some version of getaddringo somewhere will have a bug in= it which can be used to trigger a buffer overflow. If invalid data never= makes it to that code, the buffer overflow will never be triggered, at lea= st by the DHCP client. This is not an idle concern=97it's happened before= in similar situations. > (I guess the one benefit of putting in some validation text is that the I= ESG might be happier to see that? But, I wonder how much that will help as = probably the FQDN validation will provide minimal protection - as it requir= es a dot at least after every 63 characters and there is a limited characte= r set.) The problem is that IPv6 addresses aren't valid FQDNs. So you have to val= idate the address as an IPv6 address, and validate it as an FQDN. If it p= asses either validation, it's okay. From Ted.Lemon@nominum.com Thu Nov 29 09: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 0608521F8B41 for ; Thu, 29 Nov 2012 09:54:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.579 X-Spam-Level: X-Spam-Status: No, score=-106.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 wUV4YFmH9xzx for ; Thu, 29 Nov 2012 09:54:18 -0800 (PST) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id 58B8121F8B01 for ; Thu, 29 Nov 2012 09:54:15 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKULehRjf2G+cYhxiJv38YaCSABb2IjKGH@postini.com; Thu, 29 Nov 2012 09:54:15 PST 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 151631B81C5 for ; Thu, 29 Nov 2012 09:33:59 -0800 (PST) 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 0E8C1190052; Thu, 29 Nov 2012 09:33:59 -0800 (PST) (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.0318.004; Thu, 29 Nov 2012 09:33:59 -0800 From: Ted Lemon To: Danny Mayer Thread-Topic: [dhcwg] IP address vs. FQDN discussion Thread-Index: Ac29xfcgXk0oSmncRrej4Wdd4AHprgFXckYAABhv9YAAQkoKgAB3S1WAANbWQAAABN2WgACU+9KAAAAhFYAAAIQGgAAUHP9QAGBwfoAAER2KgAAMWZQAAADVrwAAA67MgAACYGoAAAF9UoA= Date: Thu, 29 Nov 2012 17:33:58 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307474178DB@mbx-01.win.nominum.com> References: <94C682931C08B048B7A8645303FDC9F36E947B0E73@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E95C9F87B@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E9751E53D@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630747410569@mbx-01.win.nominum.com> <706C6EB5-3833-46B8-B79F-B8A4340669CE@cisco.com> <50B38CE3.5060806@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B6307474137AE@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36E98722CE4@PUEXCB1B.nanterre.francetelecom.fr> <489D13FBFA9B3E41812EA89F188F018E0F5AC6FA@xmb-rcd-x04.cisco.com>, <94C682931C08B048B7A8645303FDC9F36E98AB155A@PUEXCB1B.nanterre.francetelecom.fr> <50B769DC.2080707@ntp.org> <8D23D4052ABE7A4490E77B1A012B630747417511@mbx-01.win.nominum.com> <50B79286.7090000@ntp.org> In-Reply-To: <50B79286.7090000@ntp.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: "" , "Bernie Volz \(volz\)" Subject: Re: [dhcwg] IP address vs. FQDN discussion X-BeenThere: dhcwg@ietf.org 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, 29 Nov 2012 17:54:19 -0000 On Nov 29, 2012, at 11:51 AM, Danny Mayer wrote: > There were very good reasons for this. I know you believed this, and I don't fault you for it, but you never gave = a plausible use case that could motivate the FQDN/IP address switch. The = use cases you mentioned in your reply just now are not plausible use cases,= because the first isn't addressed by DHCP, and the second is supported by = DHCP with IP addresses. > I don't know why the DHC WG wasn't doing expert review. Maybe a > discussion with Ralph Droms would be useful? The discussion already happened a while back. From volz@cisco.com Thu Nov 29 09:58: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 B695121F8AE5 for ; Thu, 29 Nov 2012 09:58:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pzTQT4LRDaMw for ; Thu, 29 Nov 2012 09:58:08 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7E50D21F8B4E for ; Thu, 29 Nov 2012 09:58:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2049; q=dns/txt; s=iport; t=1354211886; x=1355421486; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=WpAjMIPvPUyRS0PxmDhkzi59c2e8jE6OYpaHayHUODI=; b=ivtwaCHbXLybm0tABXDO51loFzI2izbAzwejeDXYftxFeZT/Z1dLCWAk 5bLpjZfHfcoNDsl60L9Elb6EEZr4cR41hwHRU+lx83TEVVx/0ifr3FIaP d3fJOxAoWJGrqvoztUAJNCLduYKYiuQ37BKlmhu2vO7WbkRlB4/KEZibc E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABSht1CtJXG//2dsb2JhbABEwBAWc4IeAQEBAwEBAQFrCwULAgEIGC4nCyUCBA4FiAoGDL8cBIxAFYNLYQOWAZBEgnKBYwIeBg X-IronPort-AV: E=McAfee;i="5400,1158,6910"; a="147640578" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-6.cisco.com with ESMTP; 29 Nov 2012 17:58:06 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id qATHw5hx000721 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 29 Nov 2012 17:58:06 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.203]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.001; Thu, 29 Nov 2012 11:58:05 -0600 From: "Bernie Volz (volz)" To: Ted Lemon Thread-Topic: [dhcwg] IP address vs. FQDN discussion Thread-Index: Ac3ES5usC9GRuubMQsaiLqHZGN/nqAFXckYAABhv9YAAQkoKgAB3S1WAANbWQAAABN2WgACU+9KAAAAhFYAAAIQGgAAUHP9QAGBwfoAAER2KgAAMWZQAAARpggAAAHJLgAAQXfMQ//JYEoCAAGJx4P//sPaA//+jI/Q= Date: Thu, 29 Nov 2012 17:58:05 +0000 Message-ID: <86FA550B-BCFA-44AC-A163-74A362382B80@cisco.com> References: <94C682931C08B048B7A8645303FDC9F36E947B0E73@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E95C9F87B@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E9751E53D@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630747410569@mbx-01.win.nominum.com> <706C6EB5-3833-46B8-B79F-B8A4340669CE@cisco.com> <50B38CE3.5060806@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B6307474137AE@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36E98722CE4@PUEXCB1B.nanterre.francetelecom.fr> <489D13FBFA9B3E41812EA89F188F018E0F5AC6FA@xmb-rcd-x04.cisco.com>, <94C682931C08B048B7A8645303FDC9F36E98AB155A@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E98AB1921@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B6307474175B6@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36E98AB1971@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B6307474176DF@mbx-01.win.nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F5BBB6A@xmb-rcd-x04.cisco.com>, <8D23D4052ABE7A4490E77B1A012B630747417891@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630747417891@mbx-01.win.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [dhcwg] IP address vs. FQDN discussion X-BeenThere: dhcwg@ietf.org 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, 29 Nov 2012 17:58:09 -0000 I wasn't saying to validate just as FQDN ... Yes, if you validation you fir= st check for addresses (v6 and/or v4) and then for FQDN. Sent from my iPad On Nov 29, 2012, at 12:30 PM, "Ted Lemon" wrote: > On Nov 29, 2012, at 11:40 AM, "Bernie Volz (volz)" > wrote: >> Are you afraid that if someone sends in some string that they can trick = the 'getaddrinfo' routine into doing something bad? Wouldn't other applicat= ions then be subject to this and wouldn't it be better to fix 'getaddrinfo'= ? >=20 > A better option, IMHO, would be to eliminate getaddrinfo, because it's a = bad idea=97the code that takes user input should decide whether the user in= put is an IP address or an FQDN, and then call the appropriate function. = Having a library function that gets unvalidated user data is broken, and if= the user data has been validated, the validator knows whether it's an IP a= ddress or an FQDN, so there's no need for a function that can handle both.= =20 >=20 > My concern is that some version of getaddringo somewhere will have a bug = in it which can be used to trigger a buffer overflow. If invalid data nev= er makes it to that code, the buffer overflow will never be triggered, at l= east by the DHCP client. This is not an idle concern=97it's happened befo= re in similar situations. >=20 >> (I guess the one benefit of putting in some validation text is that the = IESG might be happier to see that? But, I wonder how much that will help as= probably the FQDN validation will provide minimal protection - as it requi= res a dot at least after every 63 characters and there is a limited charact= er set.) >=20 > The problem is that IPv6 addresses aren't valid FQDNs. So you have to v= alidate the address as an IPv6 address, and validate it as an FQDN. If it= passes either validation, it's okay. >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From stenc@s-carlsen.dk Thu Nov 29 11:14:41 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 CC44F21F8B95 for ; Thu, 29 Nov 2012 11:14:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.289 X-Spam-Level: X-Spam-Status: No, score=-1.289 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DK=1.009, HTML_MESSAGE=0.001, J_CHICKENPOX_42=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 9WoCI1SOV2Ww for ; Thu, 29 Nov 2012 11:14:41 -0800 (PST) Received: from mail2.s-carlsen.dk (0134100024.0.fullrate.dk [90.185.128.210]) by ietfa.amsl.com (Postfix) with ESMTP id B7FB321F8B8F for ; Thu, 29 Nov 2012 11:14:40 -0800 (PST) Received: from silver4-wire.s-carlsen.dk (unknown [IPv6:2001:16d8:dd00:81ac:cabc:c8ff:fe91:1152]) by mail2.s-carlsen.dk (Postfix) with ESMTPA id 8445BFB85 for ; Thu, 29 Nov 2012 20:14:35 +0100 (CET) Message-ID: <50B7B41B.3040503@s-carlsen.dk> Date: Thu, 29 Nov 2012 20:14:35 +0100 From: Sten Carlsen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: dhcwg@ietf.org References: <94C682931C08B048B7A8645303FDC9F36E947B0E73@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E95C9F87B@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E9751E53D@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630747410569@mbx-01.win.nominum.com> <706C6EB5-3833-46B8-B79F-B8A4340669CE@cisco.com> <50B38CE3.5060806@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B6307474137AE@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36E98722CE4@PUEXCB1B.nanterre.francetelecom.fr> <489D13FBFA9B3E41812EA89F188F018E0F5AC6FA@xmb-rcd-x04.cisco.com> <94C682931C08B048B7A8645303FDC9F36E98AB155A@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B63074741747B@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63074741747B@mbx-01.win.nominum.com> X-Enigmail-Version: 1.4.6 Content-Type: multipart/alternative; boundary="------------040100010005080204040409" Subject: Re: [dhcwg] IP address vs. FQDN discussion X-BeenThere: dhcwg@ietf.org 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, 29 Nov 2012 19:14:41 -0000 This is a multi-part message in MIME format. --------------040100010005080204040409 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit On 29/11/12 16:37, Ted Lemon wrote: > On Nov 29, 2012, at 2:40 AM, mohamed.boucadair@orange.com wrote: >> (3) if option designers think only both an IP address and FQDN are needed, then adopt the format proposed in draft-boucadair-dhc-address-name-encoding. > The problem I have with this is that most of the time when people say they want both, they can't give a really good reason why they want both—they just want it. If you ask them for use cases, they can't come up with any. One good reason is that separating the management of DHCP and other services like NTP and other servers might be very good from the organisational point of view. One other such separation that is in place today is the ability to use FQDNs in host statements in DHCP.conf, one team can change things without having to wait for the other team. > > I would want the document to discourage the use of FQDNs, and to STRONGLY discourage the use of a FQDN+IP address. > > In addition, any option that did use FQDN+IP address should be REQUIRED to implement both FQDN and IP address. But I'm sure you see the problem with this—implementors often take MUST as advisory when it requires something they don't want to have to code, like a DNS resolver. So if you have an option that uses FQDN+IP, you can count on seeing serious interoperability problems in the field. > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg -- Best regards Sten Carlsen No improvements come from shouting: "MALE BOVINE MANURE!!!" --------------040100010005080204040409 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 29/11/12 16:37, Ted Lemon wrote:
On Nov 29, 2012, at 2:40 AM, mohamed.boucadair@orange.com wrote:

(3) if option designers think only both an IP address and FQDN are needed, then adopt the format proposed in draft-boucadair-dhc-address-name-encoding.

The problem I have with this is that most of the time when people say they want both, they can't give a really good reason why they want both—they just want it.   If you ask them for use cases, they can't come up with any.
One good reason is that separating the management of DHCP and other services like NTP and other servers might be very good from the organisational point of view.
One other such separation that is in place today is the ability to use FQDNs in host statements in DHCP.conf, one team can change things without having to wait for the other team.

I would want the document to discourage the use of FQDNs, and to STRONGLY discourage the use of a FQDN+IP address.

In addition, any option that did use FQDN+IP address should be REQUIRED to implement both FQDN and IP address.   But I'm sure you see the problem with this—implementors often take MUST as advisory when it requires something they don't want to have to code, like a DNS resolver.   So if you have an option that uses FQDN+IP, you can count on seeing serious interoperability problems in the field.

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


-- 
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!"
--------------040100010005080204040409-- From Ted.Lemon@nominum.com Thu Nov 29 11:20: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 1F52321F8B9E for ; Thu, 29 Nov 2012 11:20:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.58 X-Spam-Level: X-Spam-Status: No, score=-106.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 NQ7jZ0a+G7a8 for ; Thu, 29 Nov 2012 11:20:27 -0800 (PST) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id E847621F8B9A for ; Thu, 29 Nov 2012 11:20:26 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKULe1eiSlayMiJq/fUBzDXEseDgDeCIig@postini.com; Thu, 29 Nov 2012 11:20:27 PST 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 276CB1B81F2 for ; Thu, 29 Nov 2012 11:20:26 -0800 (PST) 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 1E1A5190052; Thu, 29 Nov 2012 11:20:26 -0800 (PST) (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.0318.004; Thu, 29 Nov 2012 11:20:26 -0800 From: Ted Lemon To: Sten Carlsen Thread-Topic: [dhcwg] IP address vs. FQDN discussion Thread-Index: Ac29xfcgXk0oSmncRrej4Wdd4AHprgFXckYAABhv9YAAQkoKgAB3S1WAANbWQAAABN2WgACU+9KAAAAhFYAAAIQGgAAUHP9QAGBwfoAAER2KgAAQrXuAAAeSC4AAADQCAA== Date: Thu, 29 Nov 2012 19:20:25 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630747417B0A@mbx-01.win.nominum.com> References: <94C682931C08B048B7A8645303FDC9F36E947B0E73@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E95C9F87B@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E9751E53D@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630747410569@mbx-01.win.nominum.com> <706C6EB5-3833-46B8-B79F-B8A4340669CE@cisco.com> <50B38CE3.5060806@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B6307474137AE@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36E98722CE4@PUEXCB1B.nanterre.francetelecom.fr> <489D13FBFA9B3E41812EA89F188F018E0F5AC6FA@xmb-rcd-x04.cisco.com> <94C682931C08B048B7A8645303FDC9F36E98AB155A@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B63074741747B@mbx-01.win.nominum.com> <50B7B41B.3040503@s-carlsen.dk> In-Reply-To: <50B7B41B.3040503@s-carlsen.dk> 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] IP address vs. FQDN discussion X-BeenThere: dhcwg@ietf.org 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, 29 Nov 2012 19:20:28 -0000 On Nov 29, 2012, at 2:14 PM, Sten Carlsen wrote: > One other such separation that is in place today is the ability to use FQ= DNs in host statements in DHCP.conf, one team can change things without hav= ing to wait for the other team. You can already do that. The DHCP server does the lookup instead of the c= lient. I don't ever put hard-coded IP addresses in the dhcp config databa= se! Well, except for defining address ranges and subnets, of course... (This is a feature on every DHCP server I'm aware of.) From stenc@s-carlsen.dk Thu Nov 29 11:35: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 44C9E21F8BB5 for ; Thu, 29 Nov 2012 11:35:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.489 X-Spam-Level: X-Spam-Status: No, score=-1.489 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_DK=1.009, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DpOJpTsil7yD for ; Thu, 29 Nov 2012 11:35:39 -0800 (PST) Received: from mail2.s-carlsen.dk (0134100024.0.fullrate.dk [90.185.128.210]) by ietfa.amsl.com (Postfix) with ESMTP id 761A321F8BB3 for ; Thu, 29 Nov 2012 11:35:39 -0800 (PST) Received: from silver4-wire.s-carlsen.dk (unknown [IPv6:2001:16d8:dd00:81ac:cabc:c8ff:fe91:1152]) by mail2.s-carlsen.dk (Postfix) with ESMTPA id 51502FBCE; Thu, 29 Nov 2012 20:35:35 +0100 (CET) Message-ID: <50B7B907.4080204@s-carlsen.dk> Date: Thu, 29 Nov 2012 20:35:35 +0100 From: Sten Carlsen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Ted Lemon References: <94C682931C08B048B7A8645303FDC9F36E947B0E73@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E95C9F87B@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E9751E53D@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630747410569@mbx-01.win.nominum.com> <706C6EB5-3833-46B8-B79F-B8A4340669CE@cisco.com> <50B38CE3.5060806@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B6307474137AE@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36E98722CE4@PUEXCB1B.nanterre.francetelecom.fr> <489D13FBFA9B3E41812EA89F188F018E0F5AC6FA@xmb-rcd-x04.cisco.com> <94C682931C08B048B7A8645303FDC9F36E98AB155A@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B63074741747B@mbx-01.win.nominum.com> <50B7B41B.3040503@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B630747417B0A@mbx-01.win.nominum.com > In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630747417B0A@mbx-01.win.nominum.com> X-Enigmail-Version: 1.4.6 Content-Type: multipart/alternative; boundary="------------020800000204050608050508" Cc: "" Subject: Re: [dhcwg] IP address vs. FQDN discussion X-BeenThere: dhcwg@ietf.org 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, 29 Nov 2012 19:35:40 -0000 This is a multi-part message in MIME format. --------------020800000204050608050508 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 29/11/12 20:20, Ted Lemon wrote: > On Nov 29, 2012, at 2:14 PM, Sten Carlsen wrote: >> One other such separation that is in place today is the ability to use FQDNs in host statements in DHCP.conf, one team can change things without having to wait for the other team. > You can already do that. The DHCP server does the lookup instead of the client. I don't ever put hard-coded IP addresses in the dhcp config database! Well, except for defining address ranges and subnets, of course... > > (This is a feature on every DHCP server I'm aware of.) I was believing that the lookup only happened when the server was started? Sending the FQDN would allow for changes without server restart (or I misunderstood the server operation). > -- Best regards Sten Carlsen No improvements come from shouting: "MALE BOVINE MANURE!!!" --------------020800000204050608050508 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit
On 29/11/12 20:20, Ted Lemon wrote:
On Nov 29, 2012, at 2:14 PM, Sten Carlsen <stenc@s-carlsen.dk> wrote:

One other such separation that is in place today is the ability to use FQDNs in host statements in DHCP.conf, one team can change things without having to wait for the other team.

You can already do that.   The DHCP server does the lookup instead of the client.   I don't ever put hard-coded IP addresses in the dhcp config database!   Well, except for defining address ranges and subnets, of course...

(This is a feature on every DHCP server I'm aware of.)
I was believing that the lookup only happened when the server was started? Sending the FQDN would allow for changes without server restart (or I misunderstood the server operation).



-- 
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!"
--------------020800000204050608050508-- From Ted.Lemon@nominum.com Thu Nov 29 11:50: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 A4E6921F8BFC for ; Thu, 29 Nov 2012 11:50:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.581 X-Spam-Level: X-Spam-Status: No, score=-106.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 tLwBLSZr7S-n for ; Thu, 29 Nov 2012 11:50:59 -0800 (PST) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id E0C5121F8BF6 for ; Thu, 29 Nov 2012 11:50:58 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKULe8omIwjjF75orFuTq9sJDgdJiShKK6@postini.com; Thu, 29 Nov 2012 11:50:58 PST 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 678D31B81A8 for ; Thu, 29 Nov 2012 11:50:57 -0800 (PST) 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 5DB80190052; Thu, 29 Nov 2012 11:50:57 -0800 (PST) (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.0318.004; Thu, 29 Nov 2012 11:50:57 -0800 From: Ted Lemon To: Sten Carlsen Thread-Topic: [dhcwg] IP address vs. FQDN discussion Thread-Index: Ac29xfcgXk0oSmncRrej4Wdd4AHprgFXckYAABhv9YAAQkoKgAB3S1WAANbWQAAABN2WgACU+9KAAAAhFYAAAIQGgAAUHP9QAGBwfoAAER2KgAAQrXuAAAeSC4AAADQCAAAAh8CAAACI8QA= Date: Thu, 29 Nov 2012 19:50:56 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630747417D25@mbx-01.win.nominum.com> References: <94C682931C08B048B7A8645303FDC9F36E947B0E73@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E95C9F87B@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E9751E53D@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630747410569@mbx-01.win.nominum.com> <706C6EB5-3833-46B8-B79F-B8A4340669CE@cisco.com> <50B38CE3.5060806@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B6307474137AE@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36E98722CE4@PUEXCB1B.nanterre.francetelecom.fr> <489D13FBFA9B3E41812EA89F188F018E0F5AC6FA@xmb-rcd-x04.cisco.com> <94C682931C08B048B7A8645303FDC9F36E98AB155A@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B63074741747B@mbx-01.win.nominum.com> <50B7B41B.3040503@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B630747417B0A@mbx-01.win.nominum.com > <50B7B907.4080204@s-carlsen.dk> In-Reply-To: <50B7B907.4080204@s-carlsen.dk> 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: <8252C6650099BC4888FABE5F6DF9DE90@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [dhcwg] IP address vs. FQDN discussion X-BeenThere: dhcwg@ietf.org 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, 29 Nov 2012 19:50:59 -0000 On Nov 29, 2012, at 2:35 PM, Sten Carlsen wrote: > I was believing that the lookup only happened when the server was started= ? Sending the FQDN would allow for changes without server restart (or I mis= understood the server operation). No, it happens when the DHCP client asks for a configuration. There might= be brief caching as a performance optimization that would help with freque= ntly-used names, but it's very brief=97in general implementations I've been= involved in have put a lot of trust on the local caching resolver. I thi= nk the ISC code might cache it as long as a half hour, but that's a decisio= n that=97in retrospect=97I regret. It's easy to fix if you're using the I= SC server and want a shorter cache time. From stenc@s-carlsen.dk Thu Nov 29 12:38: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 A040521F8C47 for ; Thu, 29 Nov 2012 12:38:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.514 X-Spam-Level: X-Spam-Status: No, score=-1.514 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_DK=1.009, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zfwTnuyLCgg9 for ; Thu, 29 Nov 2012 12:38:36 -0800 (PST) Received: from mail2.s-carlsen.dk (0134100024.0.fullrate.dk [90.185.128.210]) by ietfa.amsl.com (Postfix) with ESMTP id 9000C21F8C44 for ; Thu, 29 Nov 2012 12:38:35 -0800 (PST) Received: from silver4-wire.s-carlsen.dk (unknown [IPv6:2001:16d8:dd00:81ac:cabc:c8ff:fe91:1152]) by mail2.s-carlsen.dk (Postfix) with ESMTPA id 03555FBC6; Thu, 29 Nov 2012 21:38:30 +0100 (CET) Message-ID: <50B7C7C6.30403@s-carlsen.dk> Date: Thu, 29 Nov 2012 21:38:30 +0100 From: Sten Carlsen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Ted Lemon References: <94C682931C08B048B7A8645303FDC9F36E947B0E73@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E9751E53D@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630747410569@mbx-01.win.nominum.com> <706C6EB5-3833-46B8-B79F-B8A4340669CE@cisco.com> <50B38CE3.5060806@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B6307474137AE@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36E98722CE4@PUEXCB1B.nanterre.francetelecom.fr> <489D13FBFA9B3E41812EA89F188F018E0F5AC6FA@xmb-rcd-x04.cisco.com> <94C682931C08B048B7A8645303FDC9F36E98AB155A@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B63074741747B@mbx-01.win.nominum.com> <50B7B41B.3040503@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B630747417B0A@mbx-01.win.nominum.com > <50B7B907.4080204@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B630747417D25@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630747417D25@mbx-01.win.nominum.com> X-Enigmail-Version: 1.4.6 Content-Type: multipart/alternative; boundary="------------030801070409020908020904" Cc: "" Subject: Re: [dhcwg] IP address vs. FQDN discussion X-BeenThere: dhcwg@ietf.org 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, 29 Nov 2012 20:38:36 -0000 This is a multi-part message in MIME format. --------------030801070409020908020904 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit On 29/11/12 20:50, Ted Lemon wrote: > On Nov 29, 2012, at 2:35 PM, Sten Carlsen wrote: >> I was believing that the lookup only happened when the server was started? Sending the FQDN would allow for changes without server restart (or I misunderstood the server operation). > No, it happens when the DHCP client asks for a configuration. There might be brief caching as a performance optimization that would help with frequently-used names, but it's very brief—in general implementations I've been involved in have put a lot of trust on the local caching resolver. I think the ISC code might cache it as long as a half hour, but that's a decision that—in retrospect—I regret. It's easy to fix if you're using the ISC server and want a shorter cache time. > Ok, my other argument would be a name that has multiple IPs - only one can be carried. -- Best regards Sten Carlsen No improvements come from shouting: "MALE BOVINE MANURE!!!" --------------030801070409020908020904 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 29/11/12 20:50, Ted Lemon wrote:
On Nov 29, 2012, at 2:35 PM, Sten Carlsen <stenc@s-carlsen.dk> wrote:

I was believing that the lookup only happened when the server was started? Sending the FQDN would allow for changes without server restart (or I misunderstood the server operation).

No, it happens when the DHCP client asks for a configuration.   There might be brief caching as a performance optimization that would help with frequently-used names, but it's very brief—in general implementations I've been involved in have put a lot of trust on the local caching resolver.   I think the ISC code might cache it as long as a half hour, but that's a decision that—in retrospect—I regret.   It's easy to fix if you're using the ISC server and want a shorter cache time.
Ok, my other argument would be a name that has multiple IPs - only one can be carried.
-- 
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!"
--------------030801070409020908020904-- From Ted.Lemon@nominum.com Thu Nov 29 12: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 D588321F8C45 for ; Thu, 29 Nov 2012 12:45:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.582 X-Spam-Level: X-Spam-Status: No, score=-106.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 FYKhYYZ7meMb for ; Thu, 29 Nov 2012 12:45:20 -0800 (PST) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id 251CC21F8C42 for ; Thu, 29 Nov 2012 12:45:20 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKULfJX/uTI70gzYFH0Y1+8DiOscZ8q2QL@postini.com; Thu, 29 Nov 2012 12:45:20 PST 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 588DD1B81A8 for ; Thu, 29 Nov 2012 12:45:19 -0800 (PST) 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 4FCE6190052; Thu, 29 Nov 2012 12:45:19 -0800 (PST) (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.0318.004; Thu, 29 Nov 2012 12:45:19 -0800 From: Ted Lemon To: Sten Carlsen Thread-Topic: [dhcwg] IP address vs. FQDN discussion Thread-Index: Ac29xfcgXk0oSmncRrej4Wdd4AHprgFXckYAABhv9YAAQkoKgAB3S1WAANbWQAAABN2WgACU+9KAAAAhFYAAAIQGgAAUHP9QAGBwfoAAER2KgAAQrXuAAAeSC4AAADQCAAAAh8CAAACI8QAAAamTAAAAPKaA Date: Thu, 29 Nov 2012 20:45:18 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630747417E15@mbx-01.win.nominum.com> References: <94C682931C08B048B7A8645303FDC9F36E947B0E73@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E9751E53D@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630747410569@mbx-01.win.nominum.com> <706C6EB5-3833-46B8-B79F-B8A4340669CE@cisco.com> <50B38CE3.5060806@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B6307474137AE@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36E98722CE4@PUEXCB1B.nanterre.francetelecom.fr> <489D13FBFA9B3E41812EA89F188F018E0F5AC6FA@xmb-rcd-x04.cisco.com> <94C682931C08B048B7A8645303FDC9F36E98AB155A@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B63074741747B@mbx-01.win.nominum.com> <50B7B41B.3040503@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B630747417B0A@mbx-01.win.nominum.com > <50B7B907.4080204@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B630747417D25@mbx-01.win.nominum.com> <50B7C7C6.30403@s-carlsen.dk> In-Reply-To: <50B7C7C6.30403@s-carlsen.dk> 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: <070E9709862FEC4A86E6789DA769243B@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [dhcwg] IP address vs. FQDN discussion X-BeenThere: dhcwg@ietf.org 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, 29 Nov 2012 20:45:21 -0000 On Nov 29, 2012, at 3:38 PM, Sten Carlsen wrote: > Ok, my other argument would be a name that has multiple IPs - only one ca= n be carried. Again false. Most DHCP options support multiple IP addresses; if the name= resolves to more than one, each one is sent. The DHCP server can also do= load balancing, either by location or by reordering the response, but this= is not supported by all implementations (I didn't put any code like that i= n the ISC server, although someone may have in the ten years since I stoppe= d working on it!). From stenc@s-carlsen.dk Thu Nov 29 12:48: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 9705221F8C14 for ; Thu, 29 Nov 2012 12:48:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.529 X-Spam-Level: X-Spam-Status: No, score=-1.529 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_DK=1.009, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wjk+MulhmyBh for ; Thu, 29 Nov 2012 12:48:29 -0800 (PST) Received: from mail2.s-carlsen.dk (0134100024.0.fullrate.dk [90.185.128.210]) by ietfa.amsl.com (Postfix) with ESMTP id 8A0DD21F8B7F for ; Thu, 29 Nov 2012 12:48:28 -0800 (PST) Received: from silver4-wire.s-carlsen.dk (unknown [IPv6:2001:16d8:dd00:81ac:cabc:c8ff:fe91:1152]) by mail2.s-carlsen.dk (Postfix) with ESMTPA id 92A59FBC9; Thu, 29 Nov 2012 21:48:25 +0100 (CET) Message-ID: <50B7CA19.103@s-carlsen.dk> Date: Thu, 29 Nov 2012 21:48:25 +0100 From: Sten Carlsen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Ted Lemon References: <94C682931C08B048B7A8645303FDC9F36E947B0E73@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630747410569@mbx-01.win.nominum.com> <706C6EB5-3833-46B8-B79F-B8A4340669CE@cisco.com> <50B38CE3.5060806@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B6307474137AE@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36E98722CE4@PUEXCB1B.nanterre.francetelecom.fr> <489D13FBFA9B3E41812EA89F188F018E0F5AC6FA@xmb-rcd-x04.cisco.com> <94C682931C08B048B7A8645303FDC9F36E98AB155A@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B63074741747B@mbx-01.win.nominum.com> <50B7B41B.3040503@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B630747417B0A@mbx-01.win.nominum.com > <50B7B907.4080204@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B630747417D25@mbx-01.win.nominum.com> <50B7C7C6.30403@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B630747417E15@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630747417E15@mbx-01.win.nominum.com> X-Enigmail-Version: 1.4.6 Content-Type: multipart/alternative; boundary="------------000700040603020601060208" Cc: "" Subject: Re: [dhcwg] IP address vs. FQDN discussion X-BeenThere: dhcwg@ietf.org 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, 29 Nov 2012 20:48:29 -0000 This is a multi-part message in MIME format. --------------000700040603020601060208 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 29/11/12 21:45, Ted Lemon wrote: > On Nov 29, 2012, at 3:38 PM, Sten Carlsen wrote: >> Ok, my other argument would be a name that has multiple IPs - only one can be carried. > Again false. Most DHCP options support multiple IP addresses; if the name resolves to more than one, each one is sent. The DHCP server can also do load balancing, either by location or by reordering the response, but this is not supported by all implementations (I didn't put any code like that in the ISC server, although someone may have in the ten years since I stopped working on it!). > > Ok, thanks. I keep on learning about much anything. Clients may not use more than the first or last IP, but that is not going to improve by putting new text into any standard. I give upafter two tries. -- Best regards Sten Carlsen No improvements come from shouting: "MALE BOVINE MANURE!!!" --------------000700040603020601060208 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit
On 29/11/12 21:45, Ted Lemon wrote:
On Nov 29, 2012, at 3:38 PM, Sten Carlsen <stenc@s-carlsen.dk> wrote:

Ok, my other argument would be a name that has multiple IPs - only one can be carried.

Again false.   Most DHCP options support multiple IP addresses; if the name resolves to more than one, each one is sent.   The DHCP server can also do load balancing, either by location or by reordering the response, but this is not supported by all implementations (I didn't put any code like that in the ISC server, although someone may have in the ten years since I stopped working on it!).
Ok, thanks. I keep on learning about much anything.

Clients may not use more than the first or last IP, but that is not going to improve by putting new text into any standard. I give upafter two tries.

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!"
--------------000700040603020601060208-- From Ted.Lemon@nominum.com Thu Nov 29 12:53: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 7663021F8C36 for ; Thu, 29 Nov 2012 12:53:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.583 X-Spam-Level: X-Spam-Status: No, score=-106.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 fM699932C4D6 for ; Thu, 29 Nov 2012 12:53:45 -0800 (PST) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id B4ABE21F8C3F for ; Thu, 29 Nov 2012 12:53:44 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKULfLVwqu97Nq4qOjvIT82EXbz4316x1Y@postini.com; Thu, 29 Nov 2012 12:53:44 PST 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 57C961B81A8 for ; Thu, 29 Nov 2012 12:53:43 -0800 (PST) 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 4D776190052; Thu, 29 Nov 2012 12:53:43 -0800 (PST) (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.0318.004; Thu, 29 Nov 2012 12:53:43 -0800 From: Ted Lemon To: Sten Carlsen Thread-Topic: [dhcwg] IP address vs. FQDN discussion Thread-Index: Ac29xfcgXk0oSmncRrej4Wdd4AHprgFXckYAABhv9YAAQkoKgAB3S1WAANbWQAAABN2WgACU+9KAAAAhFYAAAIQGgAAUHP9QAGBwfoAAER2KgAAQrXuAAAeSC4AAADQCAAAAh8CAAACI8QAAAamTAAAAPKaAAAAcBIAAAC8WgA== Date: Thu, 29 Nov 2012 20:53:42 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630747417E80@mbx-01.win.nominum.com> References: <94C682931C08B048B7A8645303FDC9F36E947B0E73@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630747410569@mbx-01.win.nominum.com> <706C6EB5-3833-46B8-B79F-B8A4340669CE@cisco.com> <50B38CE3.5060806@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B6307474137AE@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36E98722CE4@PUEXCB1B.nanterre.francetelecom.fr> <489D13FBFA9B3E41812EA89F188F018E0F5AC6FA@xmb-rcd-x04.cisco.com> <94C682931C08B048B7A8645303FDC9F36E98AB155A@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B63074741747B@mbx-01.win.nominum.com> <50B7B41B.3040503@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B630747417B0A@mbx-01.win.nominum.com > <50B7B907.4080204@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B630747417D25@mbx-01.win.nominum.com> <50B7C7C6.30403@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B630747417E15@mbx-01.win.nominum.com> <50B7CA19.103@s-carlsen.dk> In-Reply-To: <50B7CA19.103@s-carlsen.dk> 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: <5972AC9E85ADBA48BD4C0EB35078FC28@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [dhcwg] IP address vs. FQDN discussion X-BeenThere: dhcwg@ietf.org 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, 29 Nov 2012 20:53:45 -0000 On Nov 29, 2012, at 3:48 PM, Sten Carlsen wrote: > Ok, thanks. I keep on learning about much anything. We're here to help! :) From Ted.Lemon@nominum.com Thu Nov 29 12:59: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 6638421F8B9A for ; Thu, 29 Nov 2012 12:59:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.584 X-Spam-Level: X-Spam-Status: No, score=-106.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 P9y7I5cTZpFz for ; Thu, 29 Nov 2012 12:59:19 -0800 (PST) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id B3D6421F8C48 for ; Thu, 29 Nov 2012 12:59:18 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKULfMpkBshKE2ofA+cYRKnepGKnuAb27W@postini.com; Thu, 29 Nov 2012 12:59:18 PST 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 E71401B81A8 for ; Thu, 29 Nov 2012 12:59:17 -0800 (PST) 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 DE720190052; Thu, 29 Nov 2012 12:59:17 -0800 (PST) (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.0318.004; Thu, 29 Nov 2012 12:59:18 -0800 From: Ted Lemon To: " " Thread-Topic: [dhcwg] IP address vs. FQDN discussion Thread-Index: Ac29xfcgXk0oSmncRrej4Wdd4AHprgFXckYAABhv9YAAQkoKgAB3S1WAANbWQAAABN2WgACU+9KAAAAhFYAAAIQGgAAUHP9QAGBwfoAAER2KgAAMWZQAAARpggAAAHJLgAAQXfMQ//+E4QCAAHvR8P//0e2A Date: Thu, 29 Nov 2012 20:59:17 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630747417ECE@mbx-01.win.nominum.com> References: <94C682931C08B048B7A8645303FDC9F36E947B0E73@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E95C9F87B@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E9751E53D@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630747410569@mbx-01.win.nominum.com> <706C6EB5-3833-46B8-B79F-B8A4340669CE@cisco.com> <50B38CE3.5060806@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B6307474137AE@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36E98722CE4@PUEXCB1B.nanterre.francetelecom.fr> <489D13FBFA9B3E41812EA89F188F018E0F5AC6FA@xmb-rcd-x04.cisco.com>, <94C682931C08B048B7A8645303FDC9F36E98AB155A@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E98AB1921@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B6307474175B6@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36E98AB1971@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B6307474176DF@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36E98AB19CE@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E98AB19CE@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: <9EF485C721247D469B75B2CEE7B7DD5C@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "Bernie Volz \(volz\)" Subject: Re: [dhcwg] IP address vs. FQDN discussion X-BeenThere: dhcwg@ietf.org 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, 29 Nov 2012 20:59:19 -0000 On Nov 29, 2012, at 12:01 PM, wrote: > * It is a legal UTF-8 string which does not contain any spaces > nor nulls. > * It contains IPv4 address in dotted-decimal form (e.g., > 192.0.2.33), textual representation of an IPv6 address (e.g., > 2001:db8::1) [RFC2373] [RFC5952] or a domain name (e.g., > "myservice.example.com"). Note: > + The trailing dot is optional when a domain name is conveyed > in the option. > + IPv4-mapped IPv6 addresses (e.g., ::fff:192.0.2.33) are > valid IPv6 addresses. > + IPv6 addresses MUST NOT be enclosed in brackets. No, it can't contain a dotted quad. Otherwise everybody and his brother i= s going to want a DHCPv6 option with this format so they can send IPv4 addr= esses. The right document to reference for IP addresses is RFC4291, secti= on 2.2, items 1 and 2. For domain names, you want ... Okay, I went and looked for a good referen= ce to use, and couldn't find one. This is another reason why using a text= string to solve this problem is a bad idea. There is no spec I can point= to and say "validate according to _that_." The regular DNS and IDN specs don't even refer to each other in a useful wa= y. So in practical terms, there is little chance that a validator would s= uccessfully distinguish between the set of all valid domain names and the s= et of all invalid domain names. From volz@cisco.com Thu Nov 29 14:09: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 41A4321F8C75 for ; Thu, 29 Nov 2012 14:09:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.491 X-Spam-Level: X-Spam-Status: No, score=-10.491 tagged_above=-999 required=5 tests=[AWL=0.108, 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 BgIPDnn+sdOK for ; Thu, 29 Nov 2012 14:09:34 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id A928221F8C6B for ; Thu, 29 Nov 2012 14:09:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4632; q=dns/txt; s=iport; t=1354226968; x=1355436568; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=sjET0k8V4Um8di+3RPqUZQ7SMCYInV0B+37WQLu2flw=; b=DdSP+TI8fpIXOZtmqL6K19gHpRA5EIC9sPUrHzc7Lb9Z/Lvg15VRw3Mx ZPWXLAUisqG4W0AkO//d35LVdkH6Hbimy18WUsv7tljiRXHaIEu6w/DMS c8bJ0BmTECKcfr3S10wD36DZdHpHDNwZBLaFVMfSPJ1mUMFr8TPrRaKCc M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAKjct1CtJXHB/2dsb2JhbABEwAUWc4IeAQEBBDo/DAQCAQgRBAEBAQoUCQcyFAkIAgQBDQUIiAi/H4xAg2BhA5cdjyiCcoFlJBg X-IronPort-AV: E=McAfee;i="5400,1158,6911"; a="144730088" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-9.cisco.com with ESMTP; 29 Nov 2012 22:09:28 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id qATM9SN0029387 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 29 Nov 2012 22:09:28 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.203]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.001; Thu, 29 Nov 2012 16:09:27 -0600 From: "Bernie Volz (volz)" To: Ted Lemon , " " Thread-Topic: [dhcwg] IP address vs. FQDN discussion Thread-Index: Ac3ES5usC9GRuubMQsaiLqHZGN/nqAFXckYAABhv9YAAQkoKgAB3S1WAANbWQAAABN2WgACU+9KAAAAhFYAAAIQGgAAUHP9QAGBwfoAAER2KgAAMWZQAAARpggAAAHJLgAAQXfMQ//+E4QCAAHvR8P//0e2AgA2DBSA= Date: Thu, 29 Nov 2012 22:09:27 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E0F5BD5D3@xmb-rcd-x04.cisco.com> References: <94C682931C08B048B7A8645303FDC9F36E947B0E73@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E95C9F87B@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E9751E53D@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630747410569@mbx-01.win.nominum.com> <706C6EB5-3833-46B8-B79F-B8A4340669CE@cisco.com> <50B38CE3.5060806@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B6307474137AE@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36E98722CE4@PUEXCB1B.nanterre.francetelecom.fr> <489D13FBFA9B3E41812EA89F188F018E0F5AC6FA@xmb-rcd-x04.cisco.com>, <94C682931C08B048B7A8645303FDC9F36E98AB155A@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E98AB1921@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B6307474175B6@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36E98AB1971@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B6307474176DF@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36E98AB19CE@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630747417ECE@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630747417ECE@mbx-01.win.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.245.251] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [dhcwg] IP address vs. FQDN discussion X-BeenThere: dhcwg@ietf.org 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, 29 Nov 2012 22:09:35 -0000 While I think validation just gets you into more trouble ... I believe if y= ou require this to be an ASCII formatted FQDN then I think you can validate= that there are no more than 63 characters in a label and that the characte= r set is restricted (IDNs use the ACE prefix). RFC 3490 states: An "internationalized label" is a label to which the ToASCII operation (see section 4) can be applied without failing (with the UseSTD3ASCIIRules flag unset). This implies that every ASCII label that satisfies the [STD13] length restriction is an internationalized label. Therefore the term "internationalized label" is a generalization, embracing both old ASCII labels and new non-ASCII labels. Although most Unicode characters can appear in internationalized labels, ToASCII will fail for some input strings, and such strings are not valid internationalized labels. An "internationalized domain name" (IDN) is a domain name in which every label is an internationalized label. This implies that every ASCII domain name is an IDN (which implies that it is possible for a name to be an IDN without it containing any non-ASCII characters). This document does not attempt to define an "internationalized host name". Just as has been the case with ASCII names, some DNS zone administrators may impose restrictions, beyond those imposed by DNS or IDNA, on the characters or strings that may be registered as labels in their zones. Such restrictions have no impact on the syntax or semantics of DNS protocol messages; a query for a name that matches no records will yield the same response regardless of the reason why it is not in the zone. Clients issuing queries or interpreting responses cannot be assumed to have any knowledge of zone-specific restrictions or conventions. ... To allow internationalized labels to be handled by existing applications, IDNA uses an "ACE label" (ACE stands for ASCII Compatible Encoding). An ACE label is an internationalized label that can be rendered in ASCII and is equivalent to an internationalized label that cannot be rendered in ASCII. Given any internationalized label that cannot be rendered in ASCII, the ToASCII operation will convert it to an equivalent ACE label (whereas an ASCII label will be left unaltered by ToASCII). ACE labels are unsuitable for display to users. The ToUnicode operation will convert any label to an equivalent non-ACE label. In fact, an ACE label is formally defined to be any label that the ToUnicode operation would alter (whereas non-ACE labels are left unaltered by ToUnicode). Every ACE label begins with the ACE prefix specified in section 5. The ToASCII and ToUnicode operations are specified in section 4. - Bernie -----Original Message----- From: Ted Lemon [mailto:Ted.Lemon@nominum.com]=20 Sent: Thursday, November 29, 2012 3:59 PM To: =20 Cc: Bernie Volz (volz); Subject: Re: [dhcwg] IP address vs. FQDN discussion On Nov 29, 2012, at 12:01 PM, wrote: > * It is a legal UTF-8 string which does not contain any spaces > nor nulls. > * It contains IPv4 address in dotted-decimal form (e.g., > 192.0.2.33), textual representation of an IPv6 address (e.g., > 2001:db8::1) [RFC2373] [RFC5952] or a domain name (e.g., > "myservice.example.com"). Note: > + The trailing dot is optional when a domain name is conveyed > in the option. > + IPv4-mapped IPv6 addresses (e.g., ::fff:192.0.2.33) are > valid IPv6 addresses. > + IPv6 addresses MUST NOT be enclosed in brackets. No, it can't contain a dotted quad. Otherwise everybody and his brother i= s going to want a DHCPv6 option with this format so they can send IPv4 addr= esses. The right document to reference for IP addresses is RFC4291, secti= on 2.2, items 1 and 2. For domain names, you want ... Okay, I went and looked for a good referen= ce to use, and couldn't find one. This is another reason why using a text= string to solve this problem is a bad idea. There is no spec I can point= to and say "validate according to _that_." The regular DNS and IDN specs don't even refer to each other in a useful wa= y. So in practical terms, there is little chance that a validator would s= uccessfully distinguish between the set of all valid domain names and the s= et of all invalid domain names. From mayer@ntp.org Thu Nov 29 19:11: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 F3E5A21F8448 for ; Thu, 29 Nov 2012 19:11:33 -0800 (PST) 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 DLrEUWGfSUjc for ; Thu, 29 Nov 2012 19:11:32 -0800 (PST) Received: from mx04.gis.net (mx04.gis.net [208.218.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 9C9AE21F8444 for ; Thu, 29 Nov 2012 19:11:32 -0800 (PST) Received: from [10.10.10.102] ([141.157.191.94]) by mx04.gis.net; Thu, 29 Nov 2012 22:11:26 -0500 Message-ID: <50B823DE.5070909@ntp.org> Date: Thu, 29 Nov 2012 22:11:26 -0500 From: Danny Mayer Organization: NTP User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Ted Lemon References: <94C682931C08B048B7A8645303FDC9F36E947B0E73@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E9751E53D@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630747410569@mbx-01.win.nominum.com> <706C6EB5-3833-46B8-B79F-B8A4340669CE@cisco.com> <50B38CE3.5060806@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B6307474137AE@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36E98722CE4@PUEXCB1B.nanterre.francetelecom.fr> <489D13FBFA9B3E41812EA89F188F018E0F5AC6FA@xmb-rcd-x04.cisco.com>, <94C682931C08B048B7A8645303FDC9F36E98AB155A@PUEXCB1B.nanterre.francetelecom.fr> <50B769DC.2080707@ntp.org> <8D23D4052ABE7A4490E77B1A012B630747417511@mbx-01.win.nominum.com> <50B79286.7090000@ntp.org> <8D23D4052ABE7A4490E77B1A012B6307474178DB@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307474178DB@mbx-01.win.nominum.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "" , "Bernie Volz \(volz\)" Subject: Re: [dhcwg] IP address vs. FQDN discussion X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mayer@ntp.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 03:11:34 -0000 On 11/29/2012 12:33 PM, Ted Lemon wrote: > On Nov 29, 2012, at 11:51 AM, Danny Mayer > wrote: >> There were very good reasons for this. > > I know you believed this, and I don't fault you for it, but you > never gave a plausible use case that could motivate the FQDN/IP address switch. The use cases you mentioned in your reply just now are not plausible use cases, because the first isn't addressed by DHCP, and the second is supported by DHCP with IP addresses. Among other things with a FQDN new versions of NTP will requery for IP addresses if a given address is not responding. You cannot do that if you just have an IP address. We WANT people to use FQDN's and not IP addresses to give NTP flexibility. Danny From mayer@ntp.org Thu Nov 29 19:14:13 2012 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4689721F844C for ; Thu, 29 Nov 2012 19:14:13 -0800 (PST) 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 aIpVeG-svpWP for ; Thu, 29 Nov 2012 19:14:12 -0800 (PST) Received: from mx04.gis.net (mx04.gis.net [208.218.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 9091721F8444 for ; Thu, 29 Nov 2012 19:14:12 -0800 (PST) Received: from [10.10.10.102] ([141.157.191.94]) by mx04.gis.net; Thu, 29 Nov 2012 22:14:05 -0500 Message-ID: <50B8247E.6050601@ntp.org> Date: Thu, 29 Nov 2012 22:14:06 -0500 From: Danny Mayer Organization: NTP User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Sten Carlsen References: <94C682931C08B048B7A8645303FDC9F36E947B0E73@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630747410569@mbx-01.win.nominum.com> <706C6EB5-3833-46B8-B79F-B8A4340669CE@cisco.com> <50B38CE3.5060806@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B6307474137AE@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36E98722CE4@PUEXCB1B.nanterre.francetelecom.fr> <489D13FBFA9B3E41812EA89F188F018E0F5AC6FA@xmb-rcd-x04.cisco.com> <94C682931C08B048B7A8645303FDC9F36E98AB155A@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B63074741747B@mbx-01.win.nominum.com> <50B7B41B.3040503@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B630747417B0A@mbx-01.win.nominum.com > <50B7B907.4080204@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B630747417D25@mbx-01.win.nominum.com> <50B7C7C6.30403@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B630747417E15@mbx-01.win.nominum.com> <50B7CA19.103@s-carlsen.dk> In-Reply-To: <50B7CA19.103@s-carlsen.dk> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "" , Ted Lemon Subject: Re: [dhcwg] IP address vs. FQDN discussion X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mayer@ntp.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 03:14:13 -0000 On 11/29/2012 3:48 PM, Sten Carlsen wrote: > > On 29/11/12 21:45, Ted Lemon wrote: >> On Nov 29, 2012, at 3:38 PM, Sten Carlsen wrote: >>> Ok, my other argument would be a name that has multiple IPs - only one can be carried. >> Again false. Most DHCP options support multiple IP addresses; if the name resolves to more than one, each one is sent. The DHCP server can also do load balancing, either by location or by reordering the response, but this is not supported by all implementations (I didn't put any code like that in the ISC server, although someone may have in the ten years since I stopped working on it!). >> >> > Ok, thanks. I keep on learning about much anything. > > Clients may not use more than the first or last IP, but that is not > going to improve by putting new text into any standard. I give upafter > two tries. > NTP will use all addresses it can get up to 10 if you use the pool option but it can only do that with FQDN addresses. Danny From mohamed.boucadair@orange.com Thu Nov 29 23:31: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 9C53421F8443 for ; Thu, 29 Nov 2012 23:31:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.258 X-Spam-Level: X-Spam-Status: No, score=-2.258 tagged_above=-999 required=5 tests=[AWL=-0.010, 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 tWUzF6ljXsBN for ; Thu, 29 Nov 2012 23:31:27 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id EB23821F8442 for ; Thu, 29 Nov 2012 23:31:25 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 304523B4490; Fri, 30 Nov 2012 08:31:25 +0100 (CET) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 7A9744C063; Fri, 30 Nov 2012 08:31:24 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Fri, 30 Nov 2012 08:31:24 +0100 From: To: Ted Lemon Date: Fri, 30 Nov 2012 08:31:23 +0100 Thread-Topic: [dhcwg] IP address vs. FQDN discussion Thread-Index: Ac29xfcgXk0oSmncRrej4Wdd4AHprgFXckYAABhv9YAAQkoKgAB3S1WAANbWQAAABN2WgACU+9KAAAAhFYAAAIQGgAAUHP9QAGBwfoAAER2KgAAMWZQAAARpggAAAHJLgAAQXfMQ//+E4QCAAHvR8P//0e2A///f3sA= Message-ID: <94C682931C08B048B7A8645303FDC9F36E99E2D4C8@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E947B0E73@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E95C9F87B@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E9751E53D@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630747410569@mbx-01.win.nominum.com> <706C6EB5-3833-46B8-B79F-B8A4340669CE@cisco.com> <50B38CE3.5060806@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B6307474137AE@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36E98722CE4@PUEXCB1B.nanterre.francetelecom.fr> <489D13FBFA9B3E41812EA89F188F018E0F5AC6FA@xmb-rcd-x04.cisco.com>, <94C682931C08B048B7A8645303FDC9F36E98AB155A@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E98AB1921@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B6307474175B6@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36E98AB1971@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B6307474176DF@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36E98AB19CE@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630747417ECE@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630747417ECE@mbx-01.win.nominum.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.11.29.230323 Cc: "" , "Bernie Volz \(volz\)" Subject: Re: [dhcwg] IP address vs. FQDN discussion X-BeenThere: dhcwg@ietf.org 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, 30 Nov 2012 07:31:27 -0000 Hi Ted, Please see inline. Cheers, Med=20 >-----Message d'origine----- >De : Ted Lemon [mailto:Ted.Lemon@nominum.com]=20 >Envoy=E9 : jeudi 29 novembre 2012 21:59 >=C0 : BOUCADAIR Mohamed OLNC/OLN >Cc : Bernie Volz (volz); >Objet : Re: [dhcwg] IP address vs. FQDN discussion > >On Nov 29, 2012, at 12:01 PM, > wrote: >> * It is a legal UTF-8 string which does not contain any spaces >> nor nulls. > >> * It contains IPv4 address in dotted-decimal form (e.g., >> 192.0.2.33), textual representation of an IPv6 address (e.g., >> 2001:db8::1) [RFC2373] [RFC5952] or a domain name (e.g., >> "myservice.example.com"). Note: >> + The trailing dot is optional when a domain name=20 >is conveyed >> in the option. >> + IPv4-mapped IPv6 addresses (e.g., ::fff:192.0.2.33) are >> valid IPv6 addresses. >> + IPv6 addresses MUST NOT be enclosed in brackets. > >No, it can't contain a dotted quad. Otherwise everybody and=20 >his brother is going to want a DHCPv6 option with this format=20 >so they can send IPv4 addresses.=20 Med: The rationale why I wanted to allow for this is: (1) Does dhc forbid resolving an FQDN returned in DHCPv6 to an IPv4 address= ?: No (2) Since draft-boucadair-* allows a server to resolve an FQDN and then ret= urn the result in the proposed option, an ipv4-mapped IPv6 address may be n= eeded to encode the resolved IPv4@ (3) A service can be dual stack: returning both IPv6 and IPv4-mapped IPv6 a= ddresses in one single dhcpv6 option would be appropriate.=20 The right document to=20 >reference for IP addresses is RFC4291, section 2.2, items 1 and 2. > >For domain names, you want ... Okay, I went and looked for a=20 >good reference to use, and couldn't find one. This is=20 >another reason why using a text string to solve this problem=20 >is a bad idea. There is no spec I can point to and say=20 >"validate according to _that_." > >The regular DNS and IDN specs don't even refer to each other=20 >in a useful way. So in practical terms, there is little=20 >chance that a validator would successfully distinguish between=20 >the set of all valid domain names and the set of all invalid=20 >domain names. Med: What about adding a reference to http://tools.ietf.org/html/rfc2181#se= ction-11? In particular: "The DNS itself places only one restriction on the particular labels that can be used to identify resource records. That one restriction relates to the length of the label and the full name. The length of any one label is limited to between 1 and 63 octets. A full domain name is limited to 255 octets (including the separators)." I'm fine to add this kind of validation text but requiring more than that i= s not justified IMHO. The name resolution library will have to enforce its = validation procedure anyway. If there is an attack vector against the name = resolution library, adding more validation at the dhcp client does not miti= gate the (claimed) issue as there are other means to force invoking it (emb= ed it in a webpage). We should not forget also dhcp server are required to = be configured to return valid names; otherwise access to the service will f= ail. =20 =20 From mohamed.boucadair@orange.com Thu Nov 29 23:33: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 93F0621F8447 for ; Thu, 29 Nov 2012 23:33:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.957 X-Spam-Level: X-Spam-Status: No, score=-1.957 tagged_above=-999 required=5 tests=[AWL=-0.310, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, 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 Cs+cbX5atY4T for ; Thu, 29 Nov 2012 23:33:55 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 77AEC21F8446 for ; Thu, 29 Nov 2012 23:33:55 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 9E6E518C8A1; Fri, 30 Nov 2012 08:33:54 +0100 (CET) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 7761D238061; Fri, 30 Nov 2012 08:33:54 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Fri, 30 Nov 2012 08:33:53 +0100 From: To: Sten Carlsen , "dhcwg@ietf.org" Date: Fri, 30 Nov 2012 08:33:53 +0100 Thread-Topic: [dhcwg] IP address vs. FQDN discussion Thread-Index: Ac3OZcu/FYUYojWkSjuUfR66ezKN6QAZwYQg Message-ID: <94C682931C08B048B7A8645303FDC9F36E99E2D4CC@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E947B0E73@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E95C9F87B@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E9751E53D@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630747410569@mbx-01.win.nominum.com> <706C6EB5-3833-46B8-B79F-B8A4340669CE@cisco.com> <50B38CE3.5060806@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B6307474137AE@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36E98722CE4@PUEXCB1B.nanterre.francetelecom.fr> <489D13FBFA9B3E41812EA89F188F018E0F5AC6FA@xmb-rcd-x04.cisco.com> <94C682931C08B048B7A8645303FDC9F36E98AB155A@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B63074741747B@mbx-01.win.nominum.com> <50B7B41B.3040503@s-carlsen.dk> In-Reply-To: <50B7B41B.3040503@s-carlsen.dk> 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_94C682931C08B048B7A8645303FDC9F36E99E2D4CCPUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.11.30.41521 Subject: Re: [dhcwg] IP address vs. FQDN discussion X-BeenThere: dhcwg@ietf.org 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, 30 Nov 2012 07:33:56 -0000 --_000_94C682931C08B048B7A8645303FDC9F36E99E2D4CCPUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Sten, This is indeed a valid point. The draft discusses this point here: http://tools.ietf.org/html/draft-bouca= dair-dhc-address-name-encoding-02#section-2.2.2 If you think your point is not well-covered in that text, please let me kno= w so that I can cover your point. Cheers, Med ________________________________ De : dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] De la part de S= ten Carlsen Envoy=E9 : jeudi 29 novembre 2012 20:15 =C0 : dhcwg@ietf.org Objet : Re: [dhcwg] IP address vs. FQDN discussion On 29/11/12 16:37, Ted Lemon wrote: On Nov 29, 2012, at 2:40 AM, mohamed.boucadair@orange.com wrote: (3) if option designers think only both an IP address and FQDN are needed, = then adopt the format proposed in draft-boucadair-dhc-address-name-encoding= . The problem I have with this is that most of the time when people say they = want both, they can't give a really good reason why they want both-they jus= t want it. If you ask them for use cases, they can't come up with any. One good reason is that separating the management of DHCP and other service= s like NTP and other servers might be very good from the organisational poi= nt of view. One other such separation that is in place today is the ability to use FQDN= s in host statements in DHCP.conf, one team can change things without havin= g to wait for the other team. I would want the document to discourage the use of FQDNs, and to STRONGLY d= iscourage the use of a FQDN+IP address. In addition, any option that did use FQDN+IP address should be REQUIRED to = implement both FQDN and IP address. But I'm sure you see the problem with= this-implementors often take MUST as advisory when it requires something t= hey don't want to have to code, like a DNS resolver. So if you have an op= tion that uses FQDN+IP, you can count on seeing serious interoperability pr= oblems in the field. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg -- Best regards Sten Carlsen No improvements come from shouting: "MALE BOVINE MANURE!!!" --_000_94C682931C08B048B7A8645303FDC9F36E99E2D4CCPUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear Sten,
 
This is indeed a valid point. <= /DIV>
 
The draft discusses this point here: http://tools.ietf.org/html/draft-boucadair-dhc-address-= name-encoding-02#section-2.2.2
 
If you think your point is not well-covered i= n that=20 text, please let me know so that I can cover your point.
 
Cheers,
Med
 

De : dhcwg-bounces@ietf.org=20 [mailto:dhcwg-bounces@ietf.org] De la part de Sten=20 Carlsen
Envoy=E9 : jeudi 29 novembre 2012=20 20:15
=C0 : dhcwg@ietf.org
Objet : Re: [dhc= wg] IP=20 address vs. FQDN discussion


On 29/11/12 16:37, Ted Lemon wrote:
On Nov 29, 2012, at 2:40 AM, mohamed.b=
oucadair@orange.com wrote:

(3) if option designers think =
only both an IP address and FQDN are needed, then adopt the format proposed=
 in draft-boucadair-dhc-address-name-encoding.

The problem I have with this is that most=
 of the time when people say they want both, they can't give a really good =
reason why they want both=97they just want it.   If you ask them for use ca=
ses, they can't come up with any.
One=20 good reason is that separating the management of DHCP and other services = like=20 NTP and other servers might be very good from the organisational point of= =20 view.
One other such separation that is in place today is the ability = to=20 use FQDNs in host statements in DHCP.conf, one team can change things wit= hout=20 having to wait for the other team.
I would want the document to discourage the use of FQDNs, and to STRONGLY d=
iscourage the use of a FQDN+IP address.

In addition, any option that did use FQDN+IP address should be REQUIRED to =
implement both FQDN and IP address.   But I'm sure you see the problem with=
 this=97implementors often take MUST as advisory when it requires something=
 they don't want to have to code, like a DNS resolver.   So if you have an =
option that uses FQDN+IP, you can count on seeing serious interoperability =
problems in the field.

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


--=20
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!"=20
--_000_94C682931C08B048B7A8645303FDC9F36E99E2D4CCPUEXCB1Bnante_-- From mohamed.boucadair@orange.com Thu Nov 29 23:38: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 1BA3E21F8471 for ; Thu, 29 Nov 2012 23:38:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.243 X-Spam-Level: X-Spam-Status: No, score=-2.243 tagged_above=-999 required=5 tests=[AWL=0.005, 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 bWKAYfxvoLNh for ; Thu, 29 Nov 2012 23:38:45 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 5B29121F8446 for ; Thu, 29 Nov 2012 23:38:45 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 2434D18C8B5; Fri, 30 Nov 2012 08:38:44 +0100 (CET) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 0A03127C054; Fri, 30 Nov 2012 08:38:44 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Fri, 30 Nov 2012 08:38:43 +0100 From: To: Ted Lemon , Sten Carlsen Date: Fri, 30 Nov 2012 08:38:43 +0100 Thread-Topic: [dhcwg] IP address vs. FQDN discussion Thread-Index: Ac29xfcgXk0oSmncRrej4Wdd4AHprgFXckYAABhv9YAAQkoKgAB3S1WAANbWQAAABN2WgACU+9KAAAAhFYAAAIQGgAAUHP9QAGBwfoAAER2KgAAQrXuAAAeSC4AAADQCAAAI2xqA Message-ID: <94C682931C08B048B7A8645303FDC9F36E99E2D4CF@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E947B0E73@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E95C9F87B@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E9751E53D@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630747410569@mbx-01.win.nominum.com> <706C6EB5-3833-46B8-B79F-B8A4340669CE@cisco.com> <50B38CE3.5060806@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B6307474137AE@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36E98722CE4@PUEXCB1B.nanterre.francetelecom.fr> <489D13FBFA9B3E41812EA89F188F018E0F5AC6FA@xmb-rcd-x04.cisco.com> <94C682931C08B048B7A8645303FDC9F36E98AB155A@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B63074741747B@mbx-01.win.nominum.com> <50B7B41B.3040503@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B630747417B0A@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630747417B0A@mbx-01.win.nominum.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.11.30.41521 Cc: "" Subject: Re: [dhcwg] IP address vs. FQDN discussion X-BeenThere: dhcwg@ietf.org 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, 30 Nov 2012 07:38:46 -0000 Ted, This is indeed an approach (captured here: http://tools.ietf.org/html/draft= -boucadair-dhc-address-name-encoding-02#section-2.1.1) but you may understa= nd this is not acceptable for all contexts/operators (for various reasons i= ncluding operational, network/service separation reasons, dedicated dns inf= rastructure per service, etc.).=20 Cheers, Med=20 >-----Message d'origine----- >De : dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] De=20 >la part de Ted Lemon >Envoy=E9 : jeudi 29 novembre 2012 20:20 >=C0 : Sten Carlsen >Cc : >Objet : Re: [dhcwg] IP address vs. FQDN discussion > >On Nov 29, 2012, at 2:14 PM, Sten Carlsen wrote: >> One other such separation that is in place today is the=20 >ability to use FQDNs in host statements in DHCP.conf, one team=20 >can change things without having to wait for the other team. > >You can already do that. The DHCP server does the lookup=20 >instead of the client. I don't ever put hard-coded IP=20 >addresses in the dhcp config database! Well, except for=20 >defining address ranges and subnets, of course... > >(This is a feature on every DHCP server I'm aware of.) > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www.ietf.org/mailman/listinfo/dhcwg >= From lear@cisco.com Fri Nov 30 01:04: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 83D9D21F8523 for ; Fri, 30 Nov 2012 01:04:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.313 X-Spam-Level: X-Spam-Status: No, score=-110.313 tagged_above=-999 required=5 tests=[AWL=0.286, 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 8-CG4sJWePac for ; Fri, 30 Nov 2012 01:04:31 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id AE2E721F850D for ; Fri, 30 Nov 2012 01:04:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2112; q=dns/txt; s=iport; t=1354266270; x=1355475870; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=x7Xu6aiFErIYJseqotn9MCzhNGQU1mrixZzi9qhdtks=; b=RrS5XwhK1d3FEQFGodUojmCuVg+palPxtXvulpzN4sIVHwm1nJVcBKY5 g4DE/swkAYcp6SYRZY3ntAUv8YPLwkQ6kuKcASXjkSaZAjtCnAd8cveJg hIJDrRg7rGE4r8GhR1qN1HhHXySRykJIF/ncDi7I6VtPki6EZ51ksTIjY Y=; X-IronPort-AV: E=McAfee;i="5400,1158,6911"; a="147566241" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 30 Nov 2012 09:04:29 +0000 Received: from dhcp-10-55-90-23.cisco.com (dhcp-10-55-90-23.cisco.com [10.55.90.23]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qAU94SZV026654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Nov 2012 09:04:29 GMT Message-ID: <50B8769C.4020707@cisco.com> Date: Fri, 30 Nov 2012 10:04:28 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "Bernie Volz (volz)" References: <94C682931C08B048B7A8645303FDC9F36E947B0E73@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E95C9F87B@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E9751E53D@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630747410569@mbx-01.win.nominum.com> <706C6EB5-3833-46B8-B79F-B8A4340669CE@cisco.com> <50B38CE3.5060806@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B6307474137AE@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36E98722CE4@PUEXCB1B.nanterre.francetelecom.fr> <489D13FBFA9B3E41812EA89F188F018E0F5AC6FA@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E0F5AC6FA@xmb-rcd-x04.cisco.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "" , Ted Lemon Subject: Re: [dhcwg] IP address vs. FQDN discussion X-BeenThere: dhcwg@ietf.org 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, 30 Nov 2012 09:04:31 -0000 Hi, On 11/29/12 12:30 AM, Bernie Volz (volz) wrote: > I think there was some discussion that I may have been the cause of all of this? I don't recall the particular email or discussion that might have triggered this, but I do recall several drafts proposing to use two options (or sub-options) - one for carrying the IPv4 address and another an FQDN - for a particular configuration parameter. I also recall some other drafts proposing a type enumerator followed by the data (based on the type enumerator). And, I do recall suggesting that the DHC WG perhaps take this issue up to provide some guidance as to what is the best practice (perhaps in the Options Guideline document). Personally, I do not like the idea of two options (or sub-options) and an enumeration type followed by appropriate data seems less desirable over picking one and living with it. +25. Fewer deployment choices are always better for interoperability. Perhaps some discussion around how to choose would be useful. For isntance, domain names are useful when you want to push evaluation to the client, particularly when DNS TTL semantics may not match those of DHCP. However, that can lead to an inconsistent model, where the manager of the server thinks the client is configured with one address, when it fact is configured with another. Some of this discussion might be helpful to some in making the appropriate decision, in order to help them make a choice in the protocol, and not at deployment. However... If you can't pick one, then I would argue that enumerated typing is best simply because it makes the parser simpler overall. Also, there are a number of specifications out there relating to domain names in particular that might make it hard to provide general advice. 1035 has a specification. So do 5321 and 5322. If we borrowed from 5321, SRV domains could not be transported (to give an example). That may be appropriate if the option has something to do with mail. On the other hand, if we're talking about a SIP server, SRV names are necessary. Context will matter. Eliot From budmillwood@gmail.com Fri Nov 30 01:42: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 1B4C021F84D2 for ; Fri, 30 Nov 2012 01:42:37 -0800 (PST) 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 i0hFkRyZ7pbK for ; Fri, 30 Nov 2012 01:42:36 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7257621F843E for ; Fri, 30 Nov 2012 01:42:36 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so388637ieb.31 for ; Fri, 30 Nov 2012 01:42:36 -0800 (PST) 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=h6DyzQ8+NzRxsTjGfrwUu0frj6xL0RMeBXvX/SQxDnY=; b=ItnPMHAPUQR2WwmuNmtKM/1JQu2DRToRdLaXrczFiwDuovLB5ciFn6sTo0kDjVYDyh W0YyqVf+m9C8NIlCJ/Jfa90ultJrogYSiJXurILBMa/ApGnTkhy6uacubOREwNgOjtZz LoZrjtcue0pTNC/k04EfoovTLInSci2uhyZfa4QNGaO/T/202OqQKxNbu/3kVD/F8pEJ bYC9hVEYy5B3RbQDeszJFa/G3D/2m1cvEPx/28wZ3w0Aq7sifYBYJniEzoOuIiRRhmJ4 YFQYtolV+Ig+b0XMKo24yGyfJkzZG+STV9s4IPDYZeEqF97/Ot/SPjHHv/YGPFcLtM5i YgZQ== MIME-Version: 1.0 Received: by 10.50.45.137 with SMTP id n9mr526156igm.25.1354268556051; Fri, 30 Nov 2012 01:42:36 -0800 (PST) Received: by 10.64.86.47 with HTTP; Fri, 30 Nov 2012 01:42:35 -0800 (PST) In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E0F5BBB6A@xmb-rcd-x04.cisco.com> References: <94C682931C08B048B7A8645303FDC9F36E947B0E73@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E95C9F87B@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E9751E53D@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630747410569@mbx-01.win.nominum.com> <706C6EB5-3833-46B8-B79F-B8A4340669CE@cisco.com> <50B38CE3.5060806@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B6307474137AE@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36E98722CE4@PUEXCB1B.nanterre.francetelecom.fr> <489D13FBFA9B3E41812EA89F188F018E0F5AC6FA@xmb-rcd-x04.cisco.com> <94C682931C08B048B7A8645303FDC9F36E98AB155A@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E98AB1921@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B6307474175B6@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36E98AB1971@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B6307474176DF@mbx-01.win.nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F5BBB6A@xmb-rcd-x04.cisco.com> Date: Fri, 30 Nov 2012 10:42:35 +0100 Message-ID: From: Bud Millwood To: "Bernie Volz (volz)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "" , Ted Lemon Subject: Re: [dhcwg] IP address vs. FQDN discussion X-BeenThere: dhcwg@ietf.org 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, 30 Nov 2012 09:42:37 -0000 > While I think the focus is on IPv6 (DHCPv6), I would hope that whatever w= e end up with also extends to v4 if there are new options needed there. I believe people will take the path of least resistance, choosing the proposed format for their option because it's too hard to think through whether the option really should be one format or the other. Furthermore, I think they'll justify this proposed format with the vague notion that "someone might need FQDN | IP address". And I doubt the rest of us will get much better at double checking the nature of proposed options - we're all busy - and the likely outcome is that this proposed format will become the de-facto standard. Bernie, my initial concern was that this format uses more space than the IP address format, and using the format could result in not having the option in a DHCPv4 response packets at all. - Bud > > I'm still not convinced that validating (on the client side) is worth it. > > Are you afraid that if someone sends in some string that they can trick t= he 'getaddrinfo' routine into doing something bad? Wouldn't other applicati= ons then be subject to this and wouldn't it be better to fix 'getaddrinfo'? > > (I guess the one benefit of putting in some validation text is that the I= ESG might be happier to see that? But, I wonder how much that will help as = probably the FQDN validation will provide minimal protection - as it requir= es a dot at least after every 63 characters and there is a limited characte= r set.) > > - Bernie > > -----Original Message----- > From: Ted Lemon [mailto:Ted.Lemon@nominum.com] > Sent: Thursday, November 29, 2012 11:21 AM > To: mohamed.boucadair@orange.com > Cc: Bernie Volz (volz); > Subject: Re: [dhcwg] IP address vs. FQDN discussion > > On Nov 29, 2012, at 11:12 AM, mohamed.boucadair@orange.com wrote: >> "A Name is considered as valid if it is a legitimate UTF-8 string which = does not contain any spaces nor nulls." > > No, the client needs to validate that it's either an IPv6 address or an F= QDN. The above test is certainly a good start, but it's not enough. > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From simon.perreault@viagenie.ca Fri Nov 30 02:29: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 849D021F86AC for ; Fri, 30 Nov 2012 02:29:33 -0800 (PST) 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 8lYvjU623MMx for ; Fri, 30 Nov 2012 02:29:33 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id DAD9921F84E0 for ; Fri, 30 Nov 2012 02:29:32 -0800 (PST) Received: from porto.nomis80.org (85-169-39-219.rev.numericable.fr [85.169.39.219]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 121C74038B for ; Fri, 30 Nov 2012 05:29:30 -0500 (EST) Message-ID: <50B88A85.1010602@viagenie.ca> Date: Fri, 30 Nov 2012 11:29:25 +0100 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121029 Thunderbird/16.0.2 MIME-Version: 1.0 To: dhcwg@ietf.org References: <20121126234736.GB1309@shell-too.nominum.com> In-Reply-To: <20121126234736.GB1309@shell-too.nominum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [dhcwg] DHCPv4-over-IPv6 client-side implementations? X-BeenThere: dhcwg@ietf.org 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, 30 Nov 2012 10:29:33 -0000 Le 2012-11-27 00:47, Stephen Jacob a écrit : > I know there's at least one group working on an implementation of > the client side of DHCPv4-over-IPv6 (the CRA + ?), but it is not > ready yet as I understand it. > > Do any of you know if there are any complete or mostly complete > implementations which might be used for, e.g., interop testing? Huawei demonstrated both client and server side of DHCPv4-over-IPv6 at the bits-and-bytes at IETF 85 Atlanta. 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 stenc@s-carlsen.dk Fri Nov 30 02:34: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 F325E21F86F4 for ; Fri, 30 Nov 2012 02:34:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.239 X-Spam-Level: X-Spam-Status: No, score=-1.239 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, HELO_EQ_DK=1.009, HTML_MESSAGE=0.001, J_CHICKENPOX_42=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 d2xNhyJfuITF for ; Fri, 30 Nov 2012 02:34:36 -0800 (PST) Received: from mail2.s-carlsen.dk (0134100024.0.fullrate.dk [90.185.128.210]) by ietfa.amsl.com (Postfix) with ESMTP id 6BEA721F86E8 for ; Fri, 30 Nov 2012 02:34:36 -0800 (PST) Received: from silver3airport.s-carlsen.dk (silver3AirPort.s-carlsen.dk [192.168.16.117]) by mail2.s-carlsen.dk (Postfix) with ESMTPA id 443C3FB86; Fri, 30 Nov 2012 11:34:32 +0100 (CET) Message-ID: <50B88BB7.6030005@s-carlsen.dk> Date: Fri, 30 Nov 2012 11:34:31 +0100 From: Sten Carlsen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: mohamed.boucadair@orange.com References: <94C682931C08B048B7A8645303FDC9F36E947B0E73@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E9751E53D@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630747410569@mbx-01.win.nominum.com> <706C6EB5-3833-46B8-B79F-B8A4340669CE@cisco.com> <50B38CE3.5060806@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B6307474137AE@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36E98722CE4@PUEXCB1B.nanterre.francetelecom.fr> <489D13FBFA9B3E41812EA89F188F018E0F5AC6FA@xmb-rcd-x04.cisco.com> <94C682931C08B048B7A8645303FDC9F36E98AB155A@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B63074741747B@mbx-01.win.nominum.com> <50B7B41B.3040503@s-carlsen.dk> <94C682931C08B048B7A8645303FDC9F36E99E2D4CC@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E99E2D4CC@PUEXCB1B.nanterre.francetelecom.fr> X-Enigmail-Version: 1.4.6 Content-Type: multipart/alternative; boundary="------------090105080103060704090500" Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] IP address vs. FQDN discussion X-BeenThere: dhcwg@ietf.org 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, 30 Nov 2012 10:34:39 -0000 This is a multi-part message in MIME format. --------------090105080103060704090500 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Hi As far as I can read this text is concerned about separating organisational levels in the same service, I was thinking about a slightly different situation. I see dhcp as a delivery vehicle for several different services ntp is one example, DNS is another. I believe there are many places where each service has its own maintenance crew, what I suggest is to allow for as much separation of the people looking after one service from the people looking after another service as possible. One possible way is IMHO to allow FQDNs to be passed. I also see that some clients may not be large enough to handle FQDNs. As the client includes a list of options it wants, this might be solved by having FQDNs in one option and IPs in a different one, that way a client can ask for what it can handle. Surely there are other disadvantages to this. On 30/11/12 8:33, mohamed.boucadair@orange.com wrote: > Dear Sten, > > This is indeed a valid point. > > The draft discusses this point here: > http://tools.ietf.org/html/draft-boucadair-dhc-address-name-encoding-02#section-2.2.2 > > If you think your point is not well-covered in that text, please let > me know so that I can cover your point. > > Cheers, > Med > > > ------------------------------------------------------------------------ > *De :* dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] *De > la part de* Sten Carlsen > *Envoyé :* jeudi 29 novembre 2012 20:15 > *À :* dhcwg@ietf.org > *Objet :* Re: [dhcwg] IP address vs. FQDN discussion > > > On 29/11/12 16:37, Ted Lemon wrote: >> On Nov 29, 2012, at 2:40 AM, mohamed.boucadair@orange.com wrote: >>> (3) if option designers think only both an IP address and FQDN are needed, then adopt the format proposed in draft-boucadair-dhc-address-name-encoding. >> The problem I have with this is that most of the time when people say they want both, they can't give a really good reason why they want both---they just want it. If you ask them for use cases, they can't come up with any. > One good reason is that separating the management of DHCP and > other services like NTP and other servers might be very good from > the organisational point of view. > One other such separation that is in place today is the ability to > use FQDNs in host statements in DHCP.conf, one team can change > things without having to wait for the other team. >> I would want the document to discourage the use of FQDNs, and to STRONGLY discourage the use of a FQDN+IP address. >> >> In addition, any option that did use FQDN+IP address should be REQUIRED to implement both FQDN and IP address. But I'm sure you see the problem with this---implementors often take MUST as advisory when it requires something they don't want to have to code, like a DNS resolver. So if you have an option that uses FQDN+IP, you can count on seeing serious interoperability problems in the field. >> >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg > > -- > Best regards > > Sten Carlsen > > No improvements come from shouting: > > "MALE BOVINE MANURE!!!" > -- Best regards Sten Carlsen No improvements come from shouting: "MALE BOVINE MANURE!!!" --------------090105080103060704090500 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi

As far as I can read this text is concerned about separating organisational levels in the same service, I was thinking about a slightly different situation.

I see dhcp as a delivery vehicle for several different services ntp is one example, DNS is another. I believe there are many places where each service has its own maintenance crew, what I suggest is to allow for as much separation of the people looking after one service from the people looking after another service as possible. One possible way is IMHO to allow FQDNs to be passed. I also see that some clients may not be large enough to handle FQDNs.

As the client includes a list of options it wants, this might be solved by having FQDNs in one option and IPs in a different one, that way a client can ask for what it can handle. Surely there are other disadvantages to this.

On 30/11/12 8:33, mohamed.boucadair@orange.com wrote:
Dear Sten,
 
This is indeed a valid point.
 
 
If you think your point is not well-covered in that text, please let me know so that I can cover your point.
 
Cheers,
Med
 

De : dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] De la part de Sten Carlsen
Envoyé : jeudi 29 novembre 2012 20:15
À : dhcwg@ietf.org
Objet : Re: [dhcwg] IP address vs. FQDN discussion


On 29/11/12 16:37, Ted Lemon wrote:
On Nov 29, 2012, at 2:40 AM, mohamed.boucadair@orange.com wrote:

(3) if option designers think only both an IP address and FQDN are needed, then adopt the format proposed in draft-boucadair-dhc-address-name-encoding.

The problem I have with this is that most of the time when people say they want both, they can't give a really good reason why they want both—they just want it.   If you ask them for use cases, they can't come up with any.
One good reason is that separating the management of DHCP and other services like NTP and other servers might be very good from the organisational point of view.
One other such separation that is in place today is the ability to use FQDNs in host statements in DHCP.conf, one team can change things without having to wait for the other team.
I would want the document to discourage the use of FQDNs, and to STRONGLY discourage the use of a FQDN+IP address.

In addition, any option that did use FQDN+IP address should be REQUIRED to implement both FQDN and IP address.   But I'm sure you see the problem with this—implementors often take MUST as advisory when it requires something they don't want to have to code, like a DNS resolver.   So if you have an option that uses FQDN+IP, you can count on seeing serious interoperability problems in the field.

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


-- 
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!" 


-- 
Best regards

Sten Carlsen

No improvements come from shouting:
       "MALE BOVINE MANURE!!!"
--------------090105080103060704090500-- From Ted.Lemon@nominum.com Fri Nov 30 06:07: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 C466221F8A28 for ; Fri, 30 Nov 2012 06:07:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.572 X-Spam-Level: X-Spam-Status: No, score=-106.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 a3K0M3V0q2Ca for ; Fri, 30 Nov 2012 06:07:37 -0800 (PST) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id 2090621F8A24 for ; Fri, 30 Nov 2012 06:07:37 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKULi9qNxzf5kZIf/C27Tv/g9+oxBXLVgW@postini.com; Fri, 30 Nov 2012 06:07:37 PST 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 50FDD1B81F5 for ; Fri, 30 Nov 2012 06:07:36 -0800 (PST) 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 442BA190052; Fri, 30 Nov 2012 06:07:36 -0800 (PST) (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.0318.004; Fri, 30 Nov 2012 06:07:24 -0800 From: Ted Lemon To: "" Thread-Topic: [dhcwg] IP address vs. FQDN discussion Thread-Index: Ac29xfcgXk0oSmncRrej4Wdd4AHprgFXckYAABhv9YAAQkoKgAB3S1WAANbWQAAABN2WgACU+9KAAAAhFYAAAIQGgAAUHP9QAGBwfoAAER2KgAAMWZQAAADVrwAAA67MgAACYGoAAAF9UoAAFCsaAAAW6KeA Date: Fri, 30 Nov 2012 14:07:24 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630747418EFF@mbx-01.win.nominum.com> References: <94C682931C08B048B7A8645303FDC9F36E947B0E73@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E9751E53D@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630747410569@mbx-01.win.nominum.com> <706C6EB5-3833-46B8-B79F-B8A4340669CE@cisco.com> <50B38CE3.5060806@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B6307474137AE@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36E98722CE4@PUEXCB1B.nanterre.francetelecom.fr> <489D13FBFA9B3E41812EA89F188F018E0F5AC6FA@xmb-rcd-x04.cisco.com>, <94C682931C08B048B7A8645303FDC9F36E98AB155A@PUEXCB1B.nanterre.francetelecom.fr> <50B769DC.2080707@ntp.org> <8D23D4052ABE7A4490E77B1A012B630747417511@mbx-01.win.nominum.com> <50B79286.7090000@ntp.org> <8D23D4052ABE7A4490E77B1A012B6307474178DB@mbx-01.win.nominum.com> <50B823DE.5070909@ntp.org> In-Reply-To: <50B823DE.5070909@ntp.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: "" , "Bernie Volz \(volz\)" Subject: Re: [dhcwg] IP address vs. FQDN discussion X-BeenThere: dhcwg@ietf.org 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, 30 Nov 2012 14:07:37 -0000 On Nov 29, 2012, at 10:11 PM, Danny Mayer wrote: > Among other things with a FQDN new versions of NTP will requery for IP > addresses if a given address is not responding. You cannot do that if > you just have an IP address. We WANT people to use FQDN's and not IP > addresses to give NTP flexibility. Yes, that was one of the other use cases you presented, but when asked, you= didn't say whether any implementations actually did this, nor whether any = implementations would even take an update from the DHCP client when the lea= se was renewed. In general, the existing DHCP solution of providing more t= han one IP address so that the client can alternate in the case of an outag= e, and the process of renewing leases, should adequately address this use c= ase. My experience has been that when people offer this use case and I ask them = for an example of an implementation that does this, the response is "um, uh= , let me get back to you." I would be more convinced if the response was = to tell me about a specific implementation that had some chance of seeing w= idespread deployment. From Ted.Lemon@nominum.com Fri Nov 30 06:08: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 9063021F8A43 for ; Fri, 30 Nov 2012 06:08:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.573 X-Spam-Level: X-Spam-Status: No, score=-106.573 tagged_above=-999 required=5 tests=[AWL=0.026, 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 4bdJg+FwJfnW for ; Fri, 30 Nov 2012 06:08:17 -0800 (PST) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id DA75621F89FE for ; Fri, 30 Nov 2012 06:08:16 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKULi90B0bryKIE4ESdQWEs+F1NEc6QU6h@postini.com; Fri, 30 Nov 2012 06:08:16 PST 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 30B961B81A2 for ; Fri, 30 Nov 2012 06:08:16 -0800 (PST) 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 2A50D190052; Fri, 30 Nov 2012 06:08:16 -0800 (PST) (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.0318.004; Fri, 30 Nov 2012 06:08:16 -0800 From: Ted Lemon To: "" Thread-Topic: [dhcwg] IP address vs. FQDN discussion Thread-Index: Ac29xfcgXk0oSmncRrej4Wdd4AHprgFXckYAABhv9YAAQkoKgAB3S1WAANbWQAAABN2WgACU+9KAAAAhFYAAAIQGgAAUHP9QAGBwfoAAER2KgAAQrXuAAAeSC4AAADQCAAAAh8CAAACI8QAAAamTAAAAPKaAAAAcBIAADXhHAAAW2I6A Date: Fri, 30 Nov 2012 14:08:15 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630747418F2B@mbx-01.win.nominum.com> References: <94C682931C08B048B7A8645303FDC9F36E947B0E73@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630747410569@mbx-01.win.nominum.com> <706C6EB5-3833-46B8-B79F-B8A4340669CE@cisco.com> <50B38CE3.5060806@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B6307474137AE@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36E98722CE4@PUEXCB1B.nanterre.francetelecom.fr> <489D13FBFA9B3E41812EA89F188F018E0F5AC6FA@xmb-rcd-x04.cisco.com> <94C682931C08B048B7A8645303FDC9F36E98AB155A@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B63074741747B@mbx-01.win.nominum.com> <50B7B41B.3040503@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B630747417B0A@mbx-01.win.nominum.com > <50B7B907.4080204@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B630747417D25@mbx-01.win.nominum.com> <50B7C7C6.30403@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B630747417E15@mbx-01.win.nominum.com> <50B7CA19.103@s-carlsen.dk> <50B8247E.6050601@ntp.org> In-Reply-To: <50B8247E.6050601@ntp.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: "" Subject: Re: [dhcwg] IP address vs. FQDN discussion X-BeenThere: dhcwg@ietf.org 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, 30 Nov 2012 14:08:17 -0000 On Nov 29, 2012, at 10:14 PM, Danny Mayer wrote: > NTP will use all addresses it can get up to 10 if you use the pool > option but it can only do that with FQDN addresses. So you can't give it a list of ten IP addresses, but you can give it an FQD= N? If true, this is simply an implementation bug, and requires no protoco= l action to correct. From Ted.Lemon@nominum.com Fri Nov 30 06:41: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 1504621F86DB for ; Fri, 30 Nov 2012 06:41:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.575 X-Spam-Level: X-Spam-Status: No, score=-106.575 tagged_above=-999 required=5 tests=[AWL=0.024, 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 Kjwlw1-RPdIW for ; Fri, 30 Nov 2012 06:41:36 -0800 (PST) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id B0CF821F86D8 for ; Fri, 30 Nov 2012 06:41:21 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKULjFkfLuxN8zOsucW+5irpF44t0pYBfp@postini.com; Fri, 30 Nov 2012 06:41:21 PST 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 8363E1B81F6 for ; Fri, 30 Nov 2012 06:41:20 -0800 (PST) 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 782C0190052; Fri, 30 Nov 2012 06:41:20 -0800 (PST) (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.0318.004; Fri, 30 Nov 2012 06:41:20 -0800 From: Ted Lemon To: Eliot Lear Thread-Topic: [dhcwg] IP address vs. FQDN discussion Thread-Index: Ac29xfcgXk0oSmncRrej4Wdd4AHprgFXckYAABhv9YAAQkoKgAB3S1WAANbWQAAABN2WgACU+9KAAAAhFYAAAIQGgAAUHP9QAGBwfoAARljNAAALw6yA Date: Fri, 30 Nov 2012 14:41:20 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63074741910C@mbx-01.win.nominum.com> References: <94C682931C08B048B7A8645303FDC9F36E947B0E73@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E95C9F87B@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E9751E53D@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630747410569@mbx-01.win.nominum.com> <706C6EB5-3833-46B8-B79F-B8A4340669CE@cisco.com> <50B38CE3.5060806@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B6307474137AE@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36E98722CE4@PUEXCB1B.nanterre.francetelecom.fr> <489D13FBFA9B3E41812EA89F188F018E0F5AC6FA@xmb-rcd-x04.cisco.com> <50B8769C.4020707@cisco.com> In-Reply-To: <50B8769C.4020707@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: "" , "Bernie Volz \(volz\)" Subject: Re: [dhcwg] IP address vs. FQDN discussion X-BeenThere: dhcwg@ietf.org 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, 30 Nov 2012 14:41:37 -0000 On Nov 30, 2012, at 4:04 AM, Eliot Lear wrote: > If you can't pick one, then I would argue that enumerated typing is best > simply because it makes the parser simpler overall.=20 +1 (But really, there need to be motivating use cases, not just a personal pre= ference on the part of the author.) From Ted.Lemon@nominum.com Fri Nov 30 06:43: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 A4A1521F88E9 for ; Fri, 30 Nov 2012 06:43:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.576 X-Spam-Level: X-Spam-Status: No, score=-106.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 SuY7ZQmWYWWZ for ; Fri, 30 Nov 2012 06:43:12 -0800 (PST) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id 383C921F8A73 for ; Fri, 30 Nov 2012 06:43:12 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKULjF/VRbw0NgcgJrvoGveUcEZ82dMGI/@postini.com; Fri, 30 Nov 2012 06:43:12 PST 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 0699D1B81F5 for ; Fri, 30 Nov 2012 06:43:05 -0800 (PST) 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 F3A4A190052; Fri, 30 Nov 2012 06:43:04 -0800 (PST) (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.0318.004; Fri, 30 Nov 2012 06:43:05 -0800 From: Ted Lemon To: Sten Carlsen Thread-Topic: [dhcwg] IP address vs. FQDN discussion Thread-Index: Ac29xfcgXk0oSmncRrej4Wdd4AHprgFXckYAABhv9YAAQkoKgAB3S1WAANbWQAAABN2WgACU+9KAAAAhFYAAAIQGgAAUHP9QAGBwfoAAER2KgAAQrXuAAAeSC4AAGdHcgAAGTv2AAAiuD4A= Date: Fri, 30 Nov 2012 14:43:04 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630747419142@mbx-01.win.nominum.com> References: <94C682931C08B048B7A8645303FDC9F36E947B0E73@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E9751E53D@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630747410569@mbx-01.win.nominum.com> <706C6EB5-3833-46B8-B79F-B8A4340669CE@cisco.com> <50B38CE3.5060806@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B6307474137AE@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36E98722CE4@PUEXCB1B.nanterre.francetelecom.fr> <489D13FBFA9B3E41812EA89F188F018E0F5AC6FA@xmb-rcd-x04.cisco.com> <94C682931C08B048B7A8645303FDC9F36E98AB155A@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B63074741747B@mbx-01.win.nominum.com> <50B7B41B.3040503@s-carlsen.dk> <94C682931C08B048B7A8645303FDC9F36E99E2D4CC@PUEXCB1B.nanterre.francetelecom.fr> <50B88BB7.6030005@s-carlsen.dk> In-Reply-To: <50B88BB7.6030005@s-carlsen.dk> 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@ietf.org" Subject: Re: [dhcwg] IP address vs. FQDN discussion X-BeenThere: dhcwg@ietf.org 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, 30 Nov 2012 14:43:16 -0000 On Nov 30, 2012, at 5:34 AM, Sten Carlsen wrote: > As the client includes a list of options it wants, this might be solved b= y having FQDNs in one option and IPs in a different one, that way a client = can ask for what it can handle. Surely there are other disadvantages to thi= s. Now the client has to request both, just in case only one is configured on = the server, and the server has to be configured with both, in case the clie= nt only supports one. So you've made the problem worse, not better. We'= ve trod this ground several times before... :} From Ted.Lemon@nominum.com Fri Nov 30 07:07:20 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 62F5521F8869 for ; Fri, 30 Nov 2012 07:07:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.577 X-Spam-Level: X-Spam-Status: No, score=-106.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 8iSb31E3hD4N for ; Fri, 30 Nov 2012 07:07:20 -0800 (PST) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id C02CC21F8857 for ; Fri, 30 Nov 2012 07:07:19 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKULjLp0XXktvoGgPy5FtZRv8/vdV44Oqs@postini.com; Fri, 30 Nov 2012 07:07:19 PST 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 0A14E1B8030 for ; Fri, 30 Nov 2012 07:07:19 -0800 (PST) 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 000EE190052 for ; Fri, 30 Nov 2012 07:07:18 -0800 (PST) (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.0318.004; Fri, 30 Nov 2012 07:07:19 -0800 From: Ted Lemon To: "dhcwg@ietf.org WG" Thread-Topic: Call for adoption: draft-boucadair-dhc-address-name-encoding-03 Thread-Index: AQHNzwxjqBHa9EM98km7NEBHS5Sm8g== Date: Fri, 30 Nov 2012 15:07:18 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307474192DE@mbx-01.win.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: <6DF0592F4B5B6A499A9FE94F52F91D55@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dhcwg] Call for adoption: draft-boucadair-dhc-address-name-encoding-03 X-BeenThere: dhcwg@ietf.org 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, 30 Nov 2012 15:07:20 -0000 Med has asked for a call for adoption to gauge working group consensus as t= o whether we should work on his proposal. The consensus we are trying to = get here is, is it a good idea have a DHCP option format that is a text rep= resentation of either a name or an IP address, and to recommend the use of = this format to address some use cases that might arise in the development o= f future DHCPv6 options. To be clear, this is not a consensus call on whether we should have an opti= on format representation for FQDNs: we already have one. It is not even a= consensus call on whether we should be able to have options that carry bot= h FQDNs and IP addresses=97there's already an example of such an option in = the ntp option document. This is specifically about using a UTF-8 string to carry either an FQDN or = an IP address. If you think the working group should define such an option format, please = reply to this message saying so. If you think the working group should no= t, please also reply saying so. If you have no opinion, there is no need = to respond. We will evaluate consensus on December 14. Thanks! From Ted.Lemon@nominum.com Fri Nov 30 07:14:18 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 D728721F8B17 for ; Fri, 30 Nov 2012 07:14:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.278 X-Spam-Level: X-Spam-Status: No, score=-106.278 tagged_above=-999 required=5 tests=[AWL=-0.279, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pkv6gMzbGW3t for ; Fri, 30 Nov 2012 07:14:18 -0800 (PST) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by ietfa.amsl.com (Postfix) with ESMTP id 9634721F8B04 for ; Fri, 30 Nov 2012 07:14:17 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKULjNSYpq1ZXakjVIO7aIZ/HdTQBbJ65e@postini.com; Fri, 30 Nov 2012 07:14:17 PST 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 CA5FA1B81A2 for ; Fri, 30 Nov 2012 07:14:16 -0800 (PST) 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 C1C40190052 for ; Fri, 30 Nov 2012 07:14:16 -0800 (PST) (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.0318.004; Fri, 30 Nov 2012 07:14:16 -0800 From: Ted Lemon To: "dhcwg@ietf.org WG" Thread-Topic: [dhcwg] Call for adoption: draft-boucadair-dhc-address-name-encoding-03 Thread-Index: AQHNzw1dwUbYwd+qvkerB0PfA+Tv+w== Date: Fri, 30 Nov 2012 15:14:16 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630747419370@mbx-01.win.nominum.com> References: <8D23D4052ABE7A4490E77B1A012B6307474192DE@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307474192DE@mbx-01.win.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: <4E953363AB3C96458F2D51A587405F2B@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] Call for adoption: draft-boucadair-dhc-address-name-encoding-03 X-BeenThere: dhcwg@ietf.org 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, 30 Nov 2012 15:14:19 -0000 My response to this call for adoption, wearing my working group participant= hat, not my working group chair hat, is that I strongly oppose adoption of= this work. A number of arguments have been raised in favor of doing this work, and I'v= e attempted to state my considered opinion on them below: The DHC working group long ago decided not to put dual-stack transition tec= hnology into DHCPv6. So if the motivation for using an FQDN is dual-stack= transition, this is not a good argument. And if the motivation for using= a text representation of an IPv6 address is dual-stack transition, again t= his is not a good argument. Similarly, the argument has been made that the FQDN+IP option format is nec= essary to support certain deployment strategies that are already adequately= addressed by existing technology. This again is not a good argument=97if= the existing standards already support the functionality that is needed, t= hen there is no need to extend the standards. A specific use case has been raised where the same domain name returns diff= erent results (that is to say, completely different sets of addresses) depe= nding on the location from which the query is done. And that we have to e= xtend DHCPv6 to support this use case. But this isn't a valid use case at= all, because standards-compliant DNS does not return completely different = values depending on location. If it did, this would break all kinds of th= ings=97DNSSEC, tunnels, standards-compliant local caching servers. I know that this sort of thing is done all the time in CDNs, but the fact t= hat people do it in the wild is not a reason to put it in an IETF standard. With regard to validation, the author referred to RFC2181, which says the c= ontent of labels is not restricted. But this doesn't help, because we are= not talking about the content of labels=97we are talking about a human-rea= dable presentation of the content of labels, with an undefined transform be= tween the one and the other. No document defines this transformation. T= his is why we chose to use the wire-format representation for FQDNs in DHCP= . So the bottom line is that there are a lot of really weak arguments for add= ing this complexity to DHCP. But this proposal adds significant complexit= y. I spent an hour yesterday doing a fairly thorough review of the existi= ng documents that talk about the text representation for DNS, and was unabl= e to identify a document that specifies how to validate the text representa= tion of a domain name, although many different documents talk about aspects= of how domain names are represented as text. So this proposal adds a very real attack surface to any service that uses t= his option format. There's no standard for validation that, if followed, w= ould eliminate that attack surface. And there's no compelling use case to = motivate adding it. This is why I do not support this work.= From mohamed.boucadair@orange.com Fri Nov 30 07:23:20 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 BBC3D21F8B35 for ; Fri, 30 Nov 2012 07:23:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.923 X-Spam-Level: X-Spam-Status: No, score=-1.923 tagged_above=-999 required=5 tests=[AWL=-0.275, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_42=0.6, 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 9xl0TOAvtJ6Y for ; Fri, 30 Nov 2012 07:23:20 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 66F6421F8826 for ; Fri, 30 Nov 2012 07:23:13 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id E5DEC18C55B; Fri, 30 Nov 2012 16:23:09 +0100 (CET) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id C7F23238055; Fri, 30 Nov 2012 16:23:09 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Fri, 30 Nov 2012 16:23:09 +0100 From: To: Ted Lemon , "dhcwg@ietf.org WG" Date: Fri, 30 Nov 2012 16:23:08 +0100 Thread-Topic: [dhcwg] Call for adoption: draft-boucadair-dhc-address-name-encoding-03 Thread-Index: AQHNzw1dwUbYwd+qvkerB0PfA+Tv+5gCfaNA Message-ID: <94C682931C08B048B7A8645303FDC9F36E99E2D80B@PUEXCB1B.nanterre.francetelecom.fr> References: <8D23D4052ABE7A4490E77B1A012B6307474192DE@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B630747419370@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630747419370@mbx-01.win.nominum.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.10.24.110314 Subject: Re: [dhcwg] Call for adoption: draft-boucadair-dhc-address-name-encoding-03 X-BeenThere: dhcwg@ietf.org 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, 30 Nov 2012 15:23:21 -0000 Re- FWIW, the latest version of the draft is available here: http://tools.ietf.= org/html/draft-boucadair-dhc-address-name-encoding-03 As this is a call for adoption, I would avoid answering the message below f= rom Ted. Unlike Ted, I strongly support the WG adopting this alternative encoding sc= heme which is restricted to the following scope: deployment context where b= oth an IP address and FQDN are needed. The proposed approach requires new o= ptions to justify why an IP-Address only or FQDN-only option does not meet = their requirement.=20 Cheers, Med=20 >-----Message d'origine----- >De : dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] De=20 >la part de Ted Lemon >Envoy=E9 : vendredi 30 novembre 2012 16:14 >=C0 : dhcwg@ietf.org WG >Objet : Re: [dhcwg] Call for adoption:=20 >draft-boucadair-dhc-address-name-encoding-03 > >My response to this call for adoption, wearing my working=20 >group participant hat, not my working group chair hat, is that=20 >I strongly oppose adoption of this work. > >A number of arguments have been raised in favor of doing this=20 >work, and I've attempted to state my considered opinion on them below: > >The DHC working group long ago decided not to put dual-stack=20 >transition technology into DHCPv6. So if the motivation for=20 >using an FQDN is dual-stack transition, this is not a good=20 >argument. And if the motivation for using a text=20 >representation of an IPv6 address is dual-stack transition,=20 >again this is not a good argument. > >Similarly, the argument has been made that the FQDN+IP option=20 >format is necessary to support certain deployment strategies=20 >that are already adequately addressed by existing technology. =20 > This again is not a good argument-if the existing standards=20 >already support the functionality that is needed, then there=20 >is no need to extend the standards. > >A specific use case has been raised where the same domain name=20 >returns different results (that is to say, completely=20 >different sets of addresses) depending on the location from=20 >which the query is done. And that we have to extend DHCPv6=20 >to support this use case. But this isn't a valid use case at=20 >all, because standards-compliant DNS does not return=20 >completely different values depending on location. If it=20 >did, this would break all kinds of things-DNSSEC, tunnels,=20 >standards-compliant local caching servers. > >I know that this sort of thing is done all the time in CDNs,=20 >but the fact that people do it in the wild is not a reason to=20 >put it in an IETF standard. > >With regard to validation, the author referred to RFC2181,=20 >which says the content of labels is not restricted. But this=20 >doesn't help, because we are not talking about the content of=20 >labels-we are talking about a human-readable presentation of=20 >the content of labels, with an undefined transform between the=20 >one and the other. No document defines this transformation. =20 > This is why we chose to use the wire-format representation=20 >for FQDNs in DHCP. > >So the bottom line is that there are a lot of really weak=20 >arguments for adding this complexity to DHCP. But this=20 >proposal adds significant complexity. I spent an hour=20 >yesterday doing a fairly thorough review of the existing=20 >documents that talk about the text representation for DNS, and=20 >was unable to identify a document that specifies how to=20 >validate the text representation of a domain name, although=20 >many different documents talk about aspects of how domain=20 >names are represented as text. > >So this proposal adds a very real attack surface to any=20 >service that uses this option format. There's no standard for=20 >validation that, if followed, would eliminate that attack=20 >surface. And there's no compelling use case to motivate adding it. > >This is why I do not support this work. >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www.ietf.org/mailman/listinfo/dhcwg >= From mayer@ntp.org Fri Nov 30 09:20: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 1D8E521F8965 for ; Fri, 30 Nov 2012 09:20:11 -0800 (PST) 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 uT02PFdZKAfk for ; Fri, 30 Nov 2012 09:20:10 -0800 (PST) Received: from mail1.ntp.org (mail1.ntp.org [IPv6:2001:4f8:fff7:1::5]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE4F21F8B0E for ; Fri, 30 Nov 2012 09:20:10 -0800 (PST) Received: from [198.22.153.96] (helo=[10.2.64.41]) by mail1.ntp.org with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TeUFx-000Ctv-BQ; Fri, 30 Nov 2012 17:20:06 +0000 Message-ID: <50B8EABC.5000304@ntp.org> Date: Fri, 30 Nov 2012 12:19:56 -0500 From: Danny Mayer User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Ted Lemon References: <94C682931C08B048B7A8645303FDC9F36E947B0E73@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630747410569@mbx-01.win.nominum.com> <706C6EB5-3833-46B8-B79F-B8A4340669CE@cisco.com> <50B38CE3.5060806@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B6307474137AE@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36E98722CE4@PUEXCB1B.nanterre.francetelecom.fr> <489D13FBFA9B3E41812EA89F188F018E0F5AC6FA@xmb-rcd-x04.cisco.com>, <94C682931C08B048B7A8645303FDC9F36E98AB155A@PUEXCB1B.nanterre.francetelecom.fr> <50B769DC.2080707@ntp.org> <8D23D4052ABE7A4490E77B1A012B630747417511@mbx-01.win.nominum.com> <50B79286.7090000@ntp.org> <8D23D4052ABE7A4490E77B1A012B6307474178DB@mbx-01.win.nominum.com> <50B823DE.5070909@ntp.org> <8D23D4052ABE7A4490E77B1A012B630747418EFF@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630747418EFF@mbx-01.win.nominum.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 198.22.153.96 X-SA-Exim-Rcpt-To: Ted.Lemon@nominum.com, volz@cisco.com, mohamed.boucadair@orange.com, dhcwg@ietf.org X-SA-Exim-Mail-From: mayer@ntp.org X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Cc: "" , "Bernie Volz \(volz\)" Subject: Re: [dhcwg] IP address vs. FQDN discussion X-BeenThere: dhcwg@ietf.org 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, 30 Nov 2012 17:20:11 -0000 On 11/30/2012 9:07 AM, Ted Lemon wrote: > On Nov 29, 2012, at 10:11 PM, Danny Mayer wrote: >> Among other things with a FQDN new versions of NTP will requery for IP >> addresses if a given address is not responding. You cannot do that if >> you just have an IP address. We WANT people to use FQDN's and not IP >> addresses to give NTP flexibility. > > Yes, that was one of the other use cases you presented, but when asked, you didn't say whether any implementations actually did this, nor whether any implementations would even take an update from the DHCP client when the lease was renewed. In general, the existing DHCP solution of providing more than one IP address so that the client can alternate in the case of an outage, and the process of renewing leases, should adequately address this use case. > > My experience has been that when people offer this use case and I > ask them for an example of an implementation that does this, the response is "um, uh, let me get back to you." I would be more convinced if the response was to tell me about a specific implementation that had some chance of seeing widespread deployment. > The current reference implementation of NTP has it. Danny From mayer@ntp.org Fri Nov 30 09:25:53 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 3E90C21F8B0E for ; Fri, 30 Nov 2012 09:25:53 -0800 (PST) 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 TeZIHHlEB8u7 for ; Fri, 30 Nov 2012 09:25:52 -0800 (PST) Received: from mail1.ntp.org (mail1.ntp.org [IPv6:2001:4f8:fff7:1::5]) by ietfa.amsl.com (Postfix) with ESMTP id A3CE521F8958 for ; Fri, 30 Nov 2012 09:25:52 -0800 (PST) Received: from [198.22.153.96] (helo=[10.2.64.41]) by mail1.ntp.org with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TeULV-000CwH-Rw; Fri, 30 Nov 2012 17:25:50 +0000 Message-ID: <50B8EC16.9060102@ntp.org> Date: Fri, 30 Nov 2012 12:25:42 -0500 From: Danny Mayer User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Ted Lemon References: <94C682931C08B048B7A8645303FDC9F36E947B0E73@PUEXCB1B.nanterre.francetelecom.fr> <706C6EB5-3833-46B8-B79F-B8A4340669CE@cisco.com> <50B38CE3.5060806@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B6307474137AE@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36E98722CE4@PUEXCB1B.nanterre.francetelecom.fr> <489D13FBFA9B3E41812EA89F188F018E0F5AC6FA@xmb-rcd-x04.cisco.com> <94C682931C08B048B7A8645303FDC9F36E98AB155A@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B63074741747B@mbx-01.win.nominum.com> <50B7B41B.3040503@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B630747417B0A@mbx-01.win.nominum.com > <50B7B907.4080204@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B630747417D25@mbx-01.win.nominum.com> <50B7C7C6.30403@s-carlsen.dk> <8D23D4052ABE7A4490E77B1A012B630747417E15@mbx-01.win.nominum.com> <50B7CA19.103@s-carlsen.dk> <50B8247E.6050601@ntp.org> <8D23D4052ABE7A4490E77B1A012B630747418F2B@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630747418F2B@mbx-01.win.nominum.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 198.22.153.96 X-SA-Exim-Rcpt-To: Ted.Lemon@nominum.com, stenc@s-carlsen.dk, dhcwg@ietf.org X-SA-Exim-Mail-From: mayer@ntp.org X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Cc: "" Subject: Re: [dhcwg] IP address vs. FQDN discussion X-BeenThere: dhcwg@ietf.org 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, 30 Nov 2012 17:25:53 -0000 On 11/30/2012 9:08 AM, Ted Lemon wrote: > On Nov 29, 2012, at 10:14 PM, Danny Mayer wrote: >> NTP will use all addresses it can get up to 10 if you use the pool >> option but it can only do that with FQDN addresses. > > So you can't give it a list of ten IP addresses, but you can give it an FQDN? If true, this is simply an implementation bug, and requires no protocol action to correct. No that's not true and an assumption on your part. The pool option is an implementation design and not a protocol issue. If you use the pool DNS servers (pool.ntp.org) you will get a different list of addresses every time you ask. Failure of one address will cause it to go out and find new addresses. Danny From tomasz.mrugalski@gmail.com Fri Nov 30 09:27: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 D8BEC21F8AFC for ; Fri, 30 Nov 2012 09:27:37 -0800 (PST) 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 Su4ha2rkvyRz for ; Fri, 30 Nov 2012 09:27:37 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id A671321F8ACC for ; Fri, 30 Nov 2012 09:27:36 -0800 (PST) Received: by mail-bk0-f44.google.com with SMTP id w11so369865bku.31 for ; Fri, 30 Nov 2012 09:27:35 -0800 (PST) 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:x-tagtoolbar-keys:content-type :content-transfer-encoding; bh=HwJM/5zbduwi+yByYP6RPMBxIykiR4OeZkzVU7cWawg=; b=ZKXW7653CkWcSkMbdJRni+qd7kYYiZUOsyctxVibC+Dly4oNVnDvrubjTPmwS1+Go4 OXvEcydI4lR89rMC3pFAs4Kdgi8NjOLzUBHXIc5esDRWaKUx+Hx4nDJUSdsK9o0QgyQA ZWHxI15fbG8HsxlhLIdRlTcG23yqhmDbZD4W9BIp6GgbmD3QUzptXcfzcevpVrKsOIg5 PhVn9+nd3IULZREtO0K+Bu2Eld+jUrxgBvMHUB9LzxjsvE2P1WXtrfETAE7SQz67usZq PoXfjaipWaMSYfZ6x1LqG3Bbl39wLt96pIS8+ZM+kra5UDzyIV4h0gYpSg2igRWEBFRz SIlg== Received: by 10.204.146.85 with SMTP id g21mr642790bkv.52.1354296455608; Fri, 30 Nov 2012 09:27:35 -0800 (PST) Received: from ?IPv6:2001:470:6061:1:fc6b:5bae:5f5b:baec? ([2001:470:6061:1:fc6b:5bae:5f5b:baec]) by mx.google.com with ESMTPS id e22sm4110918bke.14.2012.11.30.09.27.33 (version=SSLv3 cipher=OTHER); Fri, 30 Nov 2012 09:27:34 -0800 (PST) Message-ID: <50B8EC72.9050509@gmail.com> Date: Fri, 30 Nov 2012 18:27:14 +0100 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: dhcwg@ietf.org, Leaf yeh References: <20121129121314.23806.75684.idtracker@ietfa.amsl.com> In-Reply-To: <20121129121314.23806.75684.idtracker@ietfa.amsl.com> X-TagToolbar-Keys: D20121130182714886 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [dhcwg] Comments on draft-ietf-dhc-dhcpv6-radius-opt-05.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 17:27:38 -0000 On 29.11.2012 13:13, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. > > Title : RADIUS Option for DHCPv6 Relay Agents on Broadband Access Server > Author(s) : Leaf Y. Yeh > Mohamed Boucadair > Ted Lemon > Filename : draft-ietf-dhc-dhcpv6-radius-opt-05.txt > Pages : 9 > Date : 2012-11-29 > > Abstract: > The DHCPv6 RADIUS option provides a mechanism to exchange > authorization and identification information between relay agent and > server. This mechanism is meant for 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 Network Access Server > (NAS) acts as DHCPv6 relay agent and RADIUS client simultaneously in > this document. Here are my comments: Abstract: I think abstract could be a bit more precise in first sentence. Typically "relay agent" and "server" are obvious in the DHCP context, but when radius is mixed in, it is better to refer to them as DHCPv6 server and DHCPv6 relay. (I don't know much about radius, but googling for "radius relay" returns over 26 millions pages...) Section 1: "In this document, the DHCPv6 server is deployed in the central part of an ISP network." => "In the scenario described in this document, ..." Section 2, first sentence: The word distributed is unclear in this context. I think it should be removed (or clarified what you have in mind, as there is no such thing as distributed relay agent). Section 3: "Figure 1 and Figure 2 shows" => "Figure 1 and Figure 2 show" IPoE is not defined before. I presume it is IP over Ethernet, but it is not defined in this draft, RFC2865 or 3315, so you should explain it. On a related note, does it matter at all? Would the mechanism change if I wanted to deploy it over other access technology? I think not. A simple clarification that IPoE is just an example and this will work the same way for other access technologies would be helpful here. Perhaps you can remove "IPoE" comment altogether? In figure 1, I would position radius server and DHCPv6 server boxes differently. Aligning them one directly above another may give the impression that they are the same. The same applies to Figure 2. In the paragraph below Figure 2 there is a discussion when NAS should and shouldn't exchange data with radius server. Shouldn't that be a normative language (capital SHOULD/SHOULD NOT instead of "has"/"does not have")? General comment after figure 1 and 2: It would be useful to note somewhere that NAS keeps the information retrieved over radius, so it can be later used when REQUEST is relayed. That is perhaps obvious for people dealing with NAS, but statefulness vs statelessness is a touchy topic in DHCP world. It is better to state it clearly that this makes the relay stateful. There is nothing wrong with it, but it should be clear for implementors as this is significant change, compared to "normal" dhcpv6 relay, which is completely stateless. This comment should likely go to section 5. Section 4. Agree with previous Bernie's comments: There's no such thing as stateless option. See my suggestion about clarifying if this RADIUS option may appear when relaying inf-request and other messages. Couple comments about this sentence: "Only the attributes listed in the IANA Registry of 'RADIUS Attributes Permitted in the DHCPv6 RADIUS option' SHOULD be included in the OPTION_RADIUS." 1. It should be MAY, not SHOULD. SHOULD is almost as strong as MUST, unless there are very good reasons not to. In the current form this sentence means: you must send every attribute from the permitted attributes list, unless there is very good reason to do otherwise and all consequences of not sending it are understood. I'm sure that is not what you meant. 2. Is this really a good idea to define such a list? Some folks may have odd, but valid policies and would like to use other radius attributes. Let me give an example. If I ever run access network, I'll make sure that a user with user-name equal to tomek will get a special prefix, so I'd like my relay to convey User-Name attribute. Strange, perhaps insecure, but valid policy. Unfortunately, your current draft forbids that. 3. Having such a list is rather error-prone. I'm not sure how radext WG is organized, but I'm sure that sooner or later someone will forget to add a statement in his/her draft to add newly defined parameter to the list and it won't be allowed to be included in DHCP option. My point is that I would prefer to not have such a list at all. I would reword the text that in normal case attributes listed at the end of section 4 are useful. Other attributes may appear if they are needed. Section 5: This section lists radius parameters by name. What about new attributes? It should say "all parameters from the Permitted Radius Attributes" or something along that lines. This section should state that relay (or NAS) should keep relay responses received during SOLICIT processing, so they will be reused in REQUEST. In fact, it should be defined how long relay/nas is supposed to keep that information. What about RENEWs? It should be clarified if OPTION_RADIUS should be included just in SOLICIT/REQUEST or in other relayed messages as well (REBIND, DECLINE, CONFIRM, RELEASE, INF-REQUEST). Section 6: "If the DHCPv6 server does not support OPTION_RADIUS, the DHCPv6 server MUST silently discard this option." Server discards any unrecognised options. It is a repetition of RFC3315, but it is good to have it for clarity. Section 7: "OPTION_RADIUS is only exchanged between the relay agents and the servers." Not true. Relays send this option to servers. Servers never send it back. At least that's my understanding. Why was this changed between -04 and -05? Previous text was ok. Section 8: You should add that by successfully attacking the relay you can influence legitimate server to alter its policy. Once you have your relay compromised you are likely to have bigger problems anyway, but this should probably be mentioned. Sorry for posting my comments so late, but I was on vacation. Is the WGLC still in progress or concluded already? If it is still on-going, I support this document going forward. Cheers, Tomek