From wesley.george@twcable.com Thu Dec 1 09:29:50 2011 Return-Path: X-Original-To: renum@ietfa.amsl.com Delivered-To: renum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5850D1F0C91 for ; Thu, 1 Dec 2011 09:29:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.21 X-Spam-Level: X-Spam-Status: No, score=0.21 tagged_above=-999 required=5 tests=[AWL=-0.742, BAYES_40=-0.185, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gQPWePMa4QvY for ; Thu, 1 Dec 2011 09:29:49 -0800 (PST) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 6774E1F0C88 for ; Thu, 1 Dec 2011 09:29:49 -0800 (PST) X-SENDER-IP: 10.136.163.13 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.69,604,1315195200"; d="scan'208,217";a="304365784" Received: from unknown (HELO PRVPEXHUB04.corp.twcable.com) ([10.136.163.13]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 01 Dec 2011 12:24:48 -0500 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.26]) by PRVPEXHUB04.corp.twcable.com ([10.136.163.13]) with mapi; Thu, 1 Dec 2011 12:29:48 -0500 From: "George, Wes" To: "renum@ietf.org" Date: Thu, 1 Dec 2011 12:29:47 -0500 Thread-Topic: Meeting minutes Thread-Index: AcywTtLg1sAtv6sBT0Gh86QDkeMpzg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_DCC302FAA9FE5F4BBA4DCAD4656937791452F184C2PRVPEXVS03cor_" MIME-Version: 1.0 Subject: [renum] Meeting minutes X-BeenThere: renum@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Renumbering discussion mailing list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 17:29:50 -0000 --_000_DCC302FAA9FE5F4BBA4DCAD4656937791452F184C2PRVPEXVS03cor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Are posted... http://www.ietf.org/proceedings/82/minutes/6renum.txt Thanks, Wes ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. --_000_DCC302FAA9FE5F4BBA4DCAD4656937791452F184C2PRVPEXVS03cor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Are posted…

 

http://www.ietf.org/proceedings/82/minutes/6renum.txt

 

Thanks,

 

Wes

 


This E-mail and any of its a= ttachments may contain Time Warner Cable proprietary information, which is = privileged, confidential, or subject to copyright belonging to Time Warner = Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you a= re not the intended recipient of this E-mail, you are hereby notified that = any dissemination, distribution, copying, or action taken in relation to th= e contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have receiv= ed this E-mail in error, please notify the sender immediately and permanent= ly delete the original and any copy of this E-mail and any printout.
 --_000_DCC302FAA9FE5F4BBA4DCAD4656937791452F184C2PRVPEXVS03cor_-- From brian.e.carpenter@gmail.com Mon Dec 5 14:58:12 2011 Return-Path: X-Original-To: renum@ietfa.amsl.com Delivered-To: renum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE46921F8AA9 for ; Mon, 5 Dec 2011 14:58:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.581 X-Spam-Level: X-Spam-Status: No, score=-103.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6uwp59h3u-Y7 for ; Mon, 5 Dec 2011 14:58:12 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 64C7E21F8A91 for ; Mon, 5 Dec 2011 14:58:12 -0800 (PST) Received: by iaek3 with SMTP id k3so7490671iae.31 for ; Mon, 05 Dec 2011 14:58:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:content-type:content-transfer-encoding; bh=fq6e+YSiGKjikUOYEFBphIqi09WBeZiLZviNREkcL90=; b=CHc6C2UMzs2xKBn+ujyNXAf+Lg9lZqaqCyKVKIvFpeqPC7o1VQmqiTcSVd1fFZ1dW9 lUj2hueBMh76+qOcVmrfRsyw1r1LOJ9J2raDoapFsi5yuadNuxP2yZJkFCW+5uQvOTI0 Ff8CeIoK36KXpoaaKaZ7HT2IKpP98usfGolIQ= Received: by 10.231.65.73 with SMTP id h9mr2823262ibi.21.1323125892015; Mon, 05 Dec 2011 14:58:12 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id el2sm81714076ibb.10.2011.12.05.14.58.09 (version=SSLv3 cipher=OTHER); Mon, 05 Dec 2011 14:58:11 -0800 (PST) Message-ID: <4EDD4C83.90208@gmail.com> Date: Tue, 06 Dec 2011 11:58:11 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: renum@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [renum] Reviews requested: draft-carpenter-6renum-static-problem-01.txt X-BeenThere: renum@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Renumbering discussion mailing list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 22:58:13 -0000 Hi, This has been updated following the comments received so far. Now we are requesting reviews from the WG. Additional authors with personal expertise would be welcome too. Brian and Sheng. -------- Original Message -------- Subject: I-D Action: draft-carpenter-6renum-static-problem-01.txt Date: Mon, 05 Dec 2011 14:46:52 -0800 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Problem Statement for Renumbering IPv6 Hosts with Static Addresses Author(s) : Brian Carpenter Sheng Jiang Filename : draft-carpenter-6renum-static-problem-01.txt Pages : 10 Date : 2011-12-05 This document analyses the problems of updating the IPv6 addresses of hosts in enterprise networks that for operational reasons require static addresses. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-carpenter-6renum-static-problem-01.txt From leo.liubing@huawei.com Wed Dec 7 00:38:25 2011 Return-Path: X-Original-To: renum@ietfa.amsl.com Delivered-To: renum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5836921F848F for ; Wed, 7 Dec 2011 00:38:25 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Azj9T8NUxA8A for ; Wed, 7 Dec 2011 00:38:24 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 9143C21F848E for ; Wed, 7 Dec 2011 00:38:24 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LVT007C7RZBDK@szxga05-in.huawei.com> for renum@ietf.org; Wed, 07 Dec 2011 16:37:59 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LVT0003SRWWI6@szxga05-in.huawei.com> for renum@ietf.org; Wed, 07 Dec 2011 16:37:59 +0800 (CST) Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFP82865; Wed, 07 Dec 2011 16:37:58 +0800 Received: from SZXEML422-HUB.china.huawei.com (10.82.67.161) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 07 Dec 2011 16:37:55 +0800 Received: from SZXEML509-MBX.china.huawei.com ([169.254.1.21]) by szxeml422-hub.china.huawei.com ([10.82.67.161]) with mapi id 14.01.0323.003; Wed, 07 Dec 2011 16:37:54 +0800 Date: Wed, 07 Dec 2011 08:37:53 +0000 From: "Leo Liu(bing)" X-Originating-IP: [10.108.4.74] To: "renum@ietf.org" Message-id: <8AE0F17B87264D4CAC7DE0AA6C406F452367B80A@szxeml509-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: New Version Notification for draft-liu-6renum-gap-analysis-03.txt Thread-index: AQHMtLsQT1pg4y4QMESfc83udQ//eJXQDUyA X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Subject: [renum] FW: New Version Notification for draft-liu-6renum-gap-analysis-03.txt X-BeenThere: renum@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Renumbering discussion mailing list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2011 08:38:25 -0000 The gap revision was also based on the comments in IETF82@Taipei. Please have a review, thanks. -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Wednesday, December 07, 2011 4:33 PM To: Leo Liu(bing) Cc: Sheng Jiang; brian.e.carpenter@gmail.com; Leo Liu(bing) Subject: New Version Notification for draft-liu-6renum-gap-analysis-03.txt A new version of I-D, draft-liu-6renum-gap-analysis-03.txt has been successfully submitted by Bing Liu and posted to the IETF repository. Filename: draft-liu-6renum-gap-analysis Revision: 03 Title: IPv6 Site Renumbering Gap Analysis Creation date: 2011-12-05 WG ID: Individual Submission Number of pages: 16 Abstract: This document briefly introduces the existing mechanisms could be utilized by IPv6 site renumbering and envisions the effort could be done. This document tries to cover the most explicit issues and requirements of IPv6 renumbering. Through the gap analysis, the document provides a basis for future work to identify and develop solutions or to stimulate such development as appropriate. The gap analysis is presented following a renumbering event procedure clue. The IETF Secretariat From leo.liubing@huawei.com Wed Dec 7 00:39:23 2011 Return-Path: X-Original-To: renum@ietfa.amsl.com Delivered-To: renum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40D2121F8ACE for ; Wed, 7 Dec 2011 00:39:23 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3uJZznT50MY6 for ; Wed, 7 Dec 2011 00:39:22 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 86ADB21F8494 for ; Wed, 7 Dec 2011 00:39:22 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LVT00II4RXKKP@szxga03-in.huawei.com> for renum@ietf.org; Wed, 07 Dec 2011 16:36:56 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LVT003WQRXAO8@szxga03-in.huawei.com> for renum@ietf.org; Wed, 07 Dec 2011 16:36:56 +0800 (CST) Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFP82701; Wed, 07 Dec 2011 16:36:53 +0800 Received: from SZXEML415-HUB.china.huawei.com (10.82.67.154) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 07 Dec 2011 16:36:49 +0800 Received: from SZXEML509-MBX.china.huawei.com ([169.254.1.21]) by szxeml415-hub.china.huawei.com ([10.82.67.154]) with mapi id 14.01.0323.003; Wed, 07 Dec 2011 16:36:49 +0800 Date: Wed, 07 Dec 2011 08:36:48 +0000 From: "Leo Liu(bing)" X-Originating-IP: [10.108.4.74] To: "renum@ietf.org" Message-id: <8AE0F17B87264D4CAC7DE0AA6C406F452367B7FD@szxeml509-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: New Version Notification for draft-jiang-6renum-enterprise-02.txt Thread-index: AQHMtLraVp4Mm/bLv0SUq6yAos9PX5XQDKBA X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Subject: [renum] FW: New Version Notification for draft-jiang-6renum-enterprise-02.txt X-BeenThere: renum@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Renumbering discussion mailing list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2011 08:39:23 -0000 Hi, all The enterprise scenario document has been updated according to the comments in IETF82@Taipei. Please have a review, many thanks! -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Wednesday, December 07, 2011 4:33 PM To: Leo Liu(bing) Cc: brian.e.carpenter@gmail.com; Leo Liu(bing); Sheng Jiang Subject: New Version Notification for draft-jiang-6renum-enterprise-02.txt A new version of I-D, draft-jiang-6renum-enterprise-02.txt has been successfully submitted by Bing Liu and posted to the IETF repository. Filename: draft-jiang-6renum-enterprise Revision: 02 Title: IPv6 Enterprise Network Renumbering Scenarios and Guidelines Creation date: 2011-12-06 WG ID: Individual Submission Number of pages: 17 Abstract: This document analyzes enterprise renumbering events and describes the best current practice among the existing renumbering mechanisms. According to the different stages of renumbering events, considerations and best current practices are described in three categories: during network design, for preparation of renumbering, and during a renumbering operation. A gap inventory is listed at the end of this document. The IETF Secretariat From jiangsheng@huawei.com Thu Dec 8 22:50:11 2011 Return-Path: X-Original-To: renum@ietfa.amsl.com Delivered-To: renum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6B4E21F8541 for ; Thu, 8 Dec 2011 22:50:11 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Gj7ag+UIsOQ for ; Thu, 8 Dec 2011 22:50:10 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 63A7E21F8540 for ; Thu, 8 Dec 2011 22:50:10 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LVX00C4GCBLEN@szxga05-in.huawei.com> for renum@ietf.org; Fri, 09 Dec 2011 14:50:09 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LVX00HDSCBILC@szxga05-in.huawei.com> for renum@ietf.org; Fri, 09 Dec 2011 14:50:09 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFT09160; Fri, 09 Dec 2011 14:50:08 +0800 Received: from SZXEML420-HUB.china.huawei.com (10.82.67.159) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 09 Dec 2011 14:49:52 +0800 Received: from SZXEML506-MBX.china.huawei.com ([169.254.4.239]) by szxeml420-hub.china.huawei.com ([10.82.67.159]) with mapi id 14.01.0323.003; Fri, 09 Dec 2011 14:49:59 +0800 Date: Fri, 09 Dec 2011 06:49:58 +0000 From: Sheng Jiang In-reply-to: <5C46AA96-3CDA-41AD-8197-E7989DEC2609@gmail.com> X-Originating-IP: [10.108.4.58] To: Ran Atkinson , Brian E Carpenter , "Leo Liu(bing)" Message-id: <5D36713D8A4E7348A7E10DF7437A4B9218580CF0@SZXEML506-MBX.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-GB, zh-CN, en-US Thread-topic: draft-liu-6renum-gap-analysis-03 Thread-index: AQHMtcVRaFwaVQYHuk2tsamI5hTmaZXS0KYw X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <5C46AA96-3CDA-41AD-8197-E7989DEC2609@gmail.com> Cc: "renum@ietf.org" Subject: Re: [renum] draft-liu-6renum-gap-analysis-03 X-BeenThere: renum@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Renumbering discussion mailing list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 06:50:11 -0000 Hi, Ran, Thanks for your comments. They are quite helpful. See our replies in lines. Sheng & Bing > -----Original Message----- > From: Ran Atkinson [mailto:ran.atkinson@gmail.com] > Sent: Friday, December 09, 2011 12:20 AM > To: Brian E Carpenter > Cc: Sheng Jiang; Randall Atkinson > Subject: draft-liu-6renum-gap-analysis-03 > > Hi, > > > The above I-D in part says in Section 6.1: > > For DNS records update, most sites will achieve it by > > maintaining a DNS zone file and loading this file into the > > site's DNS server(s). Synchronization between host renumbering > > and the updating of its A6 or AAAA record is hard. [RFC5887] > > mentioned that an alternative is to use Secure Dynamic DNS > > Update [RFC3007], in which a host informs its own DNS server > > when it receives a new address. > > That description is really only true for sites that > are using BIND as their DNS server on a UNIX server, > including Linux. > > That description, however, is NOT accurate for the > many sites that are using a Microsoft Windows Server > for their DNS service or are using an Apple MacOS X > Server for their DNS service. Many many enterprises > use the Microsoft Windows Server for their DNS services; > a smaller number, but still a non-trivial number, > are using the Apple MacOS X Server for their DNS > service. > > So the quoted text above is NOT *generally* true, > and ought to be edited and corrected either to cover > the several different deployment models or to provide > a description that is generally true. Yes, our statement above is mainly based on BIND implementations. We think most of DNS servers are BIND-based, 80% and above (unverified estimation). So, Bind itself is the majority. We do not have much knowledge for Microsoft DNS or Apple DNS. Could you point out the details how they are different from our description? If the differences are magnificent, we'd like to update our description. :) > > Secure Dynamic DNS Update has been widely supported by the major > > DNS systems, but it hasn't been widely deployed, especially in > > the host. Current practices mainly involve the DHCP servers > > which act as clients to request the DNS server to update > > relevant records. Normal hosts are not suitable to do this > > mainly because of the complexity of key management issues > > inherited from secure DNS mechanisms. > > Cricket Liu appears to disagree about the deployment claim > above. His O'Reilly book "DNS & BIND" reports that Microsoft > Windows server will silently (i.e. no human involved) > ENABLE Dynamic DNS Update in a number of situations > (e.g. when that server has both DHCP and DNS services > enabled or when "Active Directory" (sic) is enabled). > > The combination of Microsoft Server (with DHCP and DNS > services enabled or "Active Directory" (sic) enabled) > with a set of Microsoft Windows clients actually is > quite common around the world in enterprise networks. > > So the claim that Secure Dynamic DNS Update is not widely > deployed seems incorrect -- primarily because many sites > have deployed it without realising they have done so. > > I would urge that the quoted text above be edited > with respect to that claim. We will contact Cricket Liu for the detail (do you have his email address?) and how common this is. We will update our text accordingly. > In Section 10, the above draft in part says: > > In the LAN, Secure DHCPv6 ([I-D.ietf-dhc-secure-dhcpv6]) or > > SeND ([RFC3971], Secure Neighbor Discovery) deployment > > may need to validate prefixes. > > > If one thinks that configuring keys for Secure Dynamic > DNS Update is difficult or challenging, then it is > unavoidable to conclude that neither Secure DHCPv6 > nor SEND are actually deployable at present. > > I think the problems with key management deserve their > own subsection in Section 10 -- as a category of "gap" > that ought to be addressed. That new subsection ought > to note the operational issues with key provisioning > and key management for Secure Dynamic DNS Update > (at least for non-MS nodes) and equally or more so > for Secure DHCPv6 and SEND. One would hope these > would not fall into the "unsolvable gap" category, > but in any event these gaps do need to be clearly > documented. The key management is a complicated issue. It is worth a separated draft. It is relevant. However, we don't think it is a renumbering specific issue. We will add some new text for it. But we would like to leave it out of scope. > Similarly, there is a practical operational "gap" in > that we have no way to automatically update ACLs during > a renumbering event. This also needs to be documented > as a gap. We did list ACL as part of filter, see Section 6.3. Best regards, Sheng > Yours, > > Ran From ran.atkinson@gmail.com Fri Dec 9 04:55:23 2011 Return-Path: X-Original-To: renum@ietfa.amsl.com Delivered-To: renum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DBF421F8483 for ; Fri, 9 Dec 2011 04:55:23 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p2QpkNAMBBp9 for ; Fri, 9 Dec 2011 04:55:22 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 642E521F8488 for ; Fri, 9 Dec 2011 04:55:22 -0800 (PST) Received: by qcsf15 with SMTP id f15so2436201qcs.31 for ; Fri, 09 Dec 2011 04:55:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=JAPH3OUvcMjEnEOUut3LqoV9DDIE/ebf+xhDRPnHUXE=; b=LmOvMuO4byUepLl0U7SvYFLcIbgsFL/5NQ6Z+2sCyTl2S7MQ297Be7Xv7hsy5FEXhR bdbsAKIB800EbfWdtG8vCQ1oxTklF5aVsHOeElGVM83gCnkSBRUOF+LhIWMikBuno8i0 xLevWYMtSUEosDO7h6LtWhmR5JA4AklYMs1vU= Received: by 10.229.71.164 with SMTP id h36mr1829570qcj.184.1323435321918; Fri, 09 Dec 2011 04:55:21 -0800 (PST) Received: from [10.30.20.12] (pool-96-225-134-175.nrflva.fios.verizon.net. [96.225.134.175]) by mx.google.com with ESMTPS id dk9sm16529500qab.0.2011.12.09.04.55.20 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 09 Dec 2011 04:55:20 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Ran Atkinson In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B9218580CF0@SZXEML506-MBX.china.huawei.com> Date: Fri, 9 Dec 2011 07:55:19 -0500 Content-Transfer-Encoding: 7bit Message-Id: <7D6F6DAB-D8B3-46AA-8339-D9B92E6356F1@gmail.com> References: <5C46AA96-3CDA-41AD-8197-E7989DEC2609@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B9218580CF0@SZXEML506-MBX.china.huawei.com> To: Sheng Jiang X-Mailer: Apple Mail (2.1251.1) X-Mailman-Approved-At: Fri, 09 Dec 2011 07:32:23 -0800 Cc: "renum@ietf.org" Subject: Re: [renum] draft-liu-6renum-gap-analysis-03 X-BeenThere: renum@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Renumbering discussion mailing list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 12:55:23 -0000 On 09 Dec 2011, at 01:49 , Sheng Jiang wrote: > Yes, our statement above is mainly based on BIND implementations. > We think most of DNS servers are BIND-based, 80% and above > (unverified estimation). So, Bind itself is the majority. BIND is quite common with ISPs and content providers, but Microsoft Server might well be the majority for *enterprise* sites. Since this document is focused on renumbering situations, Microsoft Server's DNS might well be the majority for the renumbering situation. Unlike UNIX deployments of BIND, which stand alone, Microsoft reportedly has fully integrated DNS with other services (e.g. DHCP, Windows Work groups) inside the Microsoft Windows Server. So reports say that there is no "flat file" with DNS entries. Reportedly, there is also no "loading of the DNS entries". Instead, there is full integration of DNS with the other services, and things are GUI-based and systemic for the whole deployment. I'm told that Apple's MacOS X Server takes a very similar approach to Microsoft Windows Server, with integration and a GUI front-end for the whole deployment. Apple apparently does use BIND code behind-the-scenes, but system administrators never interact with BIND directly and again there are no "flat files" to load because everything is behind a common server GUI. > We will contact Cricket Liu for the detail and > how common this is. We will update our text accordingly. Why not start first by reading his book (which is quite clear) ? It is a published O'Reilly book and should be readily available. According to the book, Microsoft Windows Server automatically enables Dynamic DNS Update between the Windows clients and the Windows server in a number of situations. So deployment of Dynamic DNS UPdate is proportional to deployments of Microsoft Windows server, which ought to be pretty common in an enterprise scenario. >> In Section 10, the above draft in part says: >>> In the LAN, Secure DHCPv6 ([I-D.ietf-dhc-secure-dhcpv6]) or >>> SeND ([RFC3971], Secure Neighbor Discovery) deployment >>> may need to validate prefixes. >> >> >> If one thinks that configuring keys for Secure Dynamic >> DNS Update is difficult or challenging, then it is >> unavoidable to conclude that neither Secure DHCPv6 >> nor SEND are actually deployable at present. >> >> I think the problems with key management deserve their >> own subsection in Section 10 -- as a category of "gap" >> that ought to be addressed. That new subsection ought >> to note the operational issues with key provisioning >> and key management for Secure Dynamic DNS Update >> (at least for non-MS nodes) and equally or more so >> for Secure DHCPv6 and SEND. One would hope these >> would not fall into the "unsolvable gap" category, >> but in any event these gaps do need to be clearly >> documented. > > The key management is a complicated issue. It is worth > a separated draft. It is relevant. However, we don't > think it is a renumbering specific issue. We will add > some new text for it. But we would like to leave it out of scope. I do not think that ignoring the issue or declaring it out-of-scope is a legitimate position to take for this document. IETF rules require that ALL documents must fully address Security Considerations *within their own document*. Ignoring that topic -- or shunting it off to other documents -- will result in a Last Call objection from me and possibly others on the very solid technical grounds that the Security Considerations are known to be deficient. >> Similarly, there is a practical operational "gap" in >> that we have no way to automatically update ACLs during >> a renumbering event. This also needs to be documented >> as a gap. > > We did list ACL as part of filter, see Section 6.3. I did. It is not nearly clear enough. More text is needed -- and since it is a Security Consideration it also needs to be referenced in the Security Considerations section of the document. Last, it is very very rude and offensive to take any private email and post it to any public mailing list without prior permission of the author -- as you have done today. Yours, Ran From marka@isc.org Fri Dec 9 14:45:51 2011 Return-Path: X-Original-To: renum@ietfa.amsl.com Delivered-To: renum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A18E421F849B for ; Fri, 9 Dec 2011 14:45:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X2BcvXxfL8PZ for ; Fri, 9 Dec 2011 14:45:51 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id A8B9D21F8496 for ; Fri, 9 Dec 2011 14:45:50 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id BE116C9479; Fri, 9 Dec 2011 22:45:38 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:44bf:4184:2d0e:dbdb]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 1BF16216C6B; Fri, 9 Dec 2011 22:45:38 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 322F11968819; Sat, 10 Dec 2011 09:45:30 +1100 (EST) To: Ran Atkinson From: Mark Andrews References: <5C46AA96-3CDA-41AD-8197-E7989DEC2609@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B9218580CF0@SZXEML506-MBX.china.huawei.com> <7D6F6DAB-D8B3-46AA-8339-D9B92E6356F1@gmail.com> In-reply-to: Your message of "Fri, 09 Dec 2011 07:55:19 CDT." <7D6F6DAB-D8B3-46AA-8339-D9B92E6356F1@gmail.com> Date: Sat, 10 Dec 2011 09:45:30 +1100 Message-Id: <20111209224530.322F11968819@drugs.dv.isc.org> Cc: "renum@ietf.org" Subject: Re: [renum] draft-liu-6renum-gap-analysis-03 X-BeenThere: renum@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Renumbering discussion mailing list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 22:45:51 -0000 In message <7D6F6DAB-D8B3-46AA-8339-D9B92E6356F1@gmail.com>, Ran Atkinson write s: > > On 09 Dec 2011, at 01:49 , Sheng Jiang wrote: > > Yes, our statement above is mainly based on BIND implementations. > > We think most of DNS servers are BIND-based, 80% and above > > (unverified estimation). So, Bind itself is the majority. > > BIND is quite common with ISPs and content providers, > but Microsoft Server might well be the majority for > *enterprise* sites. Since this document is focused > on renumbering situations, Microsoft Server's DNS > might well be the majority for the renumbering situation. > > Unlike UNIX deployments of BIND, which stand alone, > Microsoft reportedly has fully integrated DNS with > other services (e.g. DHCP, Windows Work groups) inside > the Microsoft Windows Server. > > So reports say that there is no "flat file" with DNS entries. > Reportedly, there is also no "loading of the DNS entries". > Instead, there is full integration of DNS with the > other services, and things are GUI-based and systemic > for the whole deployment. > > I'm told that Apple's MacOS X Server takes a very > similar approach to Microsoft Windows Server, with > integration and a GUI front-end for the whole deployment. > Apple apparently does use BIND code behind-the-scenes, > but system administrators never interact with BIND > directly and again there are no "flat files" to load > because everything is behind a common server GUI. > > > We will contact Cricket Liu for the detail and > > how common this is. We will update our text accordingly. > > Why not start first by reading his book (which is quite clear) ? > It is a published O'Reilly book and should be readily available. > > According to the book, Microsoft Windows Server automatically > enables Dynamic DNS Update between the Windows clients and > the Windows server in a number of situations. So deployment > of Dynamic DNS UPdate is proportional to deployments of > Microsoft Windows server, which ought to be pretty common > in an enterprise scenario. Windows uses GSS-TSIG to secure the updates. Mac OS uses TSIG to secure the updates. You turn it on via sharing presumable as Apple decided that you only need this if you need to reach the machine by name. > >> In Section 10, the above draft in part says: > >>> In the LAN, Secure DHCPv6 ([I-D.ietf-dhc-secure-dhcpv6]) or > >>> SeND ([RFC3971], Secure Neighbor Discovery) deployment > >>> may need to validate prefixes. > >> > >> > >> If one thinks that configuring keys for Secure Dynamic > >> DNS Update is difficult or challenging, then it is > >> unavoidable to conclude that neither Secure DHCPv6 > >> nor SEND are actually deployable at present. > >> > >> I think the problems with key management deserve their > >> own subsection in Section 10 -- as a category of "gap" > >> that ought to be addressed. That new subsection ought > >> to note the operational issues with key provisioning > >> and key management for Secure Dynamic DNS Update > >> (at least for non-MS nodes) and equally or more so > >> for Secure DHCPv6 and SEND. One would hope these > >> would not fall into the "unsolvable gap" category, > >> but in any event these gaps do need to be clearly > >> documented. > > > > The key management is a complicated issue. It is worth > > a separated draft. It is relevant. However, we don't > > think it is a renumbering specific issue. We will add > > some new text for it. But we would like to leave it out of scope. > > I do not think that ignoring the issue or declaring it > out-of-scope is a legitimate position to take for this > document. > > IETF rules require that ALL documents must fully address > Security Considerations *within their own document*. > > Ignoring that topic -- or shunting it off to other > documents -- will result in a Last Call objection from me > and possibly others on the very solid technical grounds > that the Security Considerations are known to be deficient. With Windows you add the machine to the domain. This is a one off procedure and the last time I did it this it needed a domain administrators password if my memory is correct. Initial registration doesn't necessarially need to be standardised. It can be ad-hoc. Log into a web page and it can return a TSIG which is configured into the nameserver and the client machine. That's done all the time to secure zone transfers. What need to be standardised is what goes on the wire and that was done years ago. The rest really is implementation detail. > >> Similarly, there is a practical operational "gap" in > >> that we have no way to automatically update ACLs during > >> a renumbering event. This also needs to be documented > >> as a gap. > > > > We did list ACL as part of filter, see Section 6.3. > > I did. It is not nearly clear enough. > > More text is needed -- and since it is a Security > Consideration it also needs to be referenced in the > Security Considerations section of the document. > > Last, it is very very rude and offensive to take any > private email and post it to any public mailing list > without prior permission of the author -- as you > have done today. > > Yours, > > Ran > > _______________________________________________ > renum mailing list > renum@ietf.org > https://www.ietf.org/mailman/listinfo/renum -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From brian.e.carpenter@gmail.com Tue Dec 13 12:11:45 2011 Return-Path: X-Original-To: renum@ietfa.amsl.com Delivered-To: renum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F19F721F8ADE for ; Tue, 13 Dec 2011 12:11:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.587 X-Spam-Level: X-Spam-Status: No, score=-103.587 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xv+8Gm9PJJ8Y for ; Tue, 13 Dec 2011 12:11:44 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4A67421F8ACA for ; Tue, 13 Dec 2011 12:11:44 -0800 (PST) Received: by iaek3 with SMTP id k3so53112iae.31 for ; Tue, 13 Dec 2011 12:11:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=hKS3l+yXwHxYQnAGv6K7gM5qTks5FAz2+zwVjhOSpsE=; b=rUtp8QBc2M728njaoK0PHKkMrWjdkL+qGNWT3dC5IrQGMu2rSTatdJ54IajtWBGi9w drwmlqfxP4LVyOUcdJuw2UxfhhQOLvi37wuYy4a/ResViSim+1pR/5gd42nEjPtYZeHp DR8NZt5oRrWpXsFClYRrh//xYw7rv5N6H/VNU= Received: by 10.50.17.165 with SMTP id p5mr20715497igd.84.1323807100592; Tue, 13 Dec 2011 12:11:40 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id zs7sm203076igb.0.2011.12.13.12.11.38 (version=SSLv3 cipher=OTHER); Tue, 13 Dec 2011 12:11:39 -0800 (PST) Message-ID: <4EE7B177.6020309@gmail.com> Date: Wed, 14 Dec 2011 09:11:35 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "renum@ietf.org" References: <5C46AA96-3CDA-41AD-8197-E7989DEC2609@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B9218580CF0@SZXEML506-MBX.china.huawei.com> <7D6F6DAB-D8B3-46AA-8339-D9B92E6356F1@gmail.com> <20111209224530.322F11968819@drugs.dv.isc.org> In-Reply-To: <20111209224530.322F11968819@drugs.dv.isc.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [renum] Key management [draft-liu-6renum-gap-analysis-03] X-BeenThere: renum@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Renumbering discussion mailing list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2011 20:11:45 -0000 On 2011-12-10 11:45, Mark Andrews wrote: > In message <7D6F6DAB-D8B3-46AA-8339-D9B92E6356F1@gmail.com>, Ran Atkinson write > s: ... >>>> I think the problems with key management deserve their >>>> own subsection in Section 10 -- as a category of "gap" >>>> that ought to be addressed. That new subsection ought >>>> to note the operational issues with key provisioning >>>> and key management for Secure Dynamic DNS Update >>>> (at least for non-MS nodes) and equally or more so >>>> for Secure DHCPv6 and SEND. One would hope these >>>> would not fall into the "unsolvable gap" category, >>>> but in any event these gaps do need to be clearly >>>> documented. >>> The key management is a complicated issue. It is worth >>> a separated draft. It is relevant. However, we don't >>> think it is a renumbering specific issue. We will add >>> some new text for it. But we would like to leave it out of scope. >> I do not think that ignoring the issue or declaring it >> out-of-scope is a legitimate position to take for this >> document. >> >> IETF rules require that ALL documents must fully address >> Security Considerations *within their own document*. >> >> Ignoring that topic -- or shunting it off to other >> documents -- will result in a Last Call objection from me >> and possibly others on the very solid technical grounds >> that the Security Considerations are known to be deficient. Right, but the question is what can we say about key management that is specific to enterprise renumbering? We can explain the problem, but this is presumably not the WG where a solution should be developed. > With Windows you add the machine to the domain. This is a > one off procedure and the last time I did it this it needed > a domain administrators password if my memory is correct. > > Initial registration doesn't necessarially need to be standardised. > It can be ad-hoc. Log into a web page and it can return a TSIG > which is configured into the nameserver and the client machine. > > That's done all the time to secure zone transfers. > > What need to be standardised is what goes on the wire and that > was done years ago. The rest really is implementation detail. Really? It seems to me that the Windows solution will only work for a Microsoft shop, not for a heterogeneous enterprise network. Brian From marka@isc.org Tue Dec 13 17:43:46 2011 Return-Path: X-Original-To: renum@ietfa.amsl.com Delivered-To: renum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8B6F21F8ACE for ; Tue, 13 Dec 2011 17:43:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1pbw4+yljf0J for ; Tue, 13 Dec 2011 17:43:42 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 8BA2021F84C9 for ; Tue, 13 Dec 2011 17:43:41 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id D17AE5F9891; Wed, 14 Dec 2011 01:43:26 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:9dbe:1913:d1c:b98c]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id C2D7B216C6A; Wed, 14 Dec 2011 01:43:24 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 722571A078FB; Wed, 14 Dec 2011 12:43:22 +1100 (EST) To: Brian E Carpenter From: Mark Andrews References: <5C46AA96-3CDA-41AD-8197-E7989DEC2609@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B9218580CF0@SZXEML506-MBX.china.huawei.com> <7D6F6DAB-D8B3-46AA-8339-D9B92E6356F1@gmail.com> <20111209224530.322F11968819@drugs.dv.isc.org> <4EE7B177.6020309@gmail.com> In-reply-to: Your message of "Wed, 14 Dec 2011 09:11:35 +1300." <4EE7B177.6020309@gmail.com> Date: Wed, 14 Dec 2011 12:43:22 +1100 Message-Id: <20111214014322.722571A078FB@drugs.dv.isc.org> Cc: "renum@ietf.org" Subject: Re: [renum] Key management [draft-liu-6renum-gap-analysis-03] X-BeenThere: renum@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Renumbering discussion mailing list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2011 01:43:47 -0000 In message <4EE7B177.6020309@gmail.com>, Brian E Carpenter writes: > On 2011-12-10 11:45, Mark Andrews wrote: > > In message <7D6F6DAB-D8B3-46AA-8339-D9B92E6356F1@gmail.com>, Ran Atkinson write > > s: > > ... > >>>> I think the problems with key management deserve their > >>>> own subsection in Section 10 -- as a category of "gap" > >>>> that ought to be addressed. That new subsection ought > >>>> to note the operational issues with key provisioning > >>>> and key management for Secure Dynamic DNS Update > >>>> (at least for non-MS nodes) and equally or more so > >>>> for Secure DHCPv6 and SEND. One would hope these > >>>> would not fall into the "unsolvable gap" category, > >>>> but in any event these gaps do need to be clearly > >>>> documented. > > >>> The key management is a complicated issue. It is worth > >>> a separated draft. It is relevant. However, we don't > >>> think it is a renumbering specific issue. We will add > >>> some new text for it. But we would like to leave it out of scope. > >> I do not think that ignoring the issue or declaring it > >> out-of-scope is a legitimate position to take for this > >> document. > >> > >> IETF rules require that ALL documents must fully address > >> Security Considerations *within their own document*. > >> > >> Ignoring that topic -- or shunting it off to other > >> documents -- will result in a Last Call objection from me > >> and possibly others on the very solid technical grounds > >> that the Security Considerations are known to be deficient. > > Right, but the question is what can we say about key management > that is specific to enterprise renumbering? We can explain the > problem, but this is presumably not the WG where a solution should > be developed. > > > With Windows you add the machine to the domain. This is a > > one off procedure and the last time I did it this it needed > > a domain administrators password if my memory is correct. > > > > Initial registration doesn't necessarially need to be standardised. > > It can be ad-hoc. Log into a web page and it can return a TSIG > > which is configured into the nameserver and the client machine. > > > > That's done all the time to secure zone transfers. > > > > What need to be standardised is what goes on the wire and that > > was done years ago. The rest really is implementation detail. > > Really? It seems to me that the Windows solution will only work for > a Microsoft shop, not for a heterogeneous enterprise network. If you really want a mechanism to do this then something like this will work: If the machine does not already have a configured TSIG (RFC 2845) it will generate a one time public/private key pair and send the public key along with a request for a TSIG to update the forward zone in a DHCP request. The DHCP server will make a TKEY (RFC 2930) request, on behalf of the client, using its credentials to the DNS server and return the resulting TSIG key to the client encrypting the TSIG option response using the public key in the request. The returned TSIG key should be stored in non-volatile memory. The DHCP server operates as the secure introducer to the DNS server. One would probably want to signal if the TSIG request is for globally or locally unique name and be able to request both. This will allow the host to update multiple namespaces by using the different TSIGs Different DHCP server credentials could be used to signal this or we could specify a TKEY option. ULA/RFC 1918 would be private addresses and would only be addded to the local name space. We can do something similar for PPP. Security considerations: If the DHCP option is responded to by a rogue server the worst is a denial of service attack. The DHCP server can pretend to be the DHCP client as it has seen the TSIG material. > Brian > _______________________________________________ > renum mailing list > renum@ietf.org > https://www.ietf.org/mailman/listinfo/renum -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From leo.liubing@huawei.com Tue Dec 13 19:05:36 2011 Return-Path: X-Original-To: renum@ietfa.amsl.com Delivered-To: renum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1BC511E8095 for ; Tue, 13 Dec 2011 19:05:36 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y64KfaRSjYfX for ; Tue, 13 Dec 2011 19:05:36 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id A372E11E8089 for ; Tue, 13 Dec 2011 19:05:35 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LW6006E8B6FV8@szxga04-in.huawei.com> for renum@ietf.org; Wed, 14 Dec 2011 11:03:51 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LW600LBSB6FP8@szxga04-in.huawei.com> for renum@ietf.org; Wed, 14 Dec 2011 11:03:51 +0800 (CST) Received: from szxeml206-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFR03182; Wed, 14 Dec 2011 11:03:41 +0800 Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 14 Dec 2011 11:03:38 +0800 Received: from SZXEML509-MBX.china.huawei.com ([169.254.1.21]) by szxeml402-hub.china.huawei.com ([10.82.67.32]) with mapi id 14.01.0323.003; Wed, 14 Dec 2011 11:03:31 +0800 Date: Wed, 14 Dec 2011 03:03:29 +0000 From: "Leo Liu(bing)" In-reply-to: <7D6F6DAB-D8B3-46AA-8339-D9B92E6356F1@gmail.com> X-Originating-IP: [10.108.4.74] To: Ran Atkinson , Sheng Jiang Message-id: <8AE0F17B87264D4CAC7DE0AA6C406F452367F927@szxeml509-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: draft-liu-6renum-gap-analysis-03 Thread-index: AQHMtcVRaFwaVQYHuk2tsamI5hTmaZXS0KYwgAAhT4CAB6fV0A== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <5C46AA96-3CDA-41AD-8197-E7989DEC2609@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B9218580CF0@SZXEML506-MBX.china.huawei.com> <7D6F6DAB-D8B3-46AA-8339-D9B92E6356F1@gmail.com> Cc: "renum@ietf.org" Subject: Re: [renum] draft-liu-6renum-gap-analysis-03 X-BeenThere: renum@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Renumbering discussion mailing list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2011 03:05:36 -0000 Hi, Ran Thanks for your comments. See replies inline please. > -----Original Message----- > From: Ran Atkinson [mailto:ran.atkinson@gmail.com] > Sent: Friday, December 09, 2011 8:55 PM > To: Sheng Jiang > Cc: Brian E Carpenter; Leo Liu(bing); renum@ietf.org > Subject: Re: draft-liu-6renum-gap-analysis-03 > > > On 09 Dec 2011, at 01:49 , Sheng Jiang wrote: > > Yes, our statement above is mainly based on BIND implementations. > > We think most of DNS servers are BIND-based, 80% and above > > (unverified estimation). So, Bind itself is the majority. > > BIND is quite common with ISPs and content providers, > but Microsoft Server might well be the majority for > *enterprise* sites. Since this document is focused > on renumbering situations, Microsoft Server's DNS > might well be the majority for the renumbering situation. > [Bing] Our company also uses Microsoft, I think we need a brief investigation on whether it is quite common, then we can update the draft accordingly. > Unlike UNIX deployments of BIND, which stand alone, > Microsoft reportedly has fully integrated DNS with > other services (e.g. DHCP, Windows Work groups) inside > the Microsoft Windows Server. > > So reports say that there is no "flat file" with DNS entries. > Reportedly, there is also no "loading of the DNS entries". > Instead, there is full integration of DNS with the > other services, and things are GUI-based and systemic > for the whole deployment. > > I'm told that Apple's MacOS X Server takes a very > similar approach to Microsoft Windows Server, with > integration and a GUI front-end for the whole deployment. > Apple apparently does use BIND code behind-the-scenes, > but system administrators never interact with BIND > directly and again there are no "flat files" to load > because everything is behind a common server GUI. > [Bing] If it is true, I think we can add something like "if you deploy Microsoft/apple, the DDNS issue is much easier" after the relevant gap analysis. The gap itself is still meaningful, since it is a real problem if we didn't deploy the integrated solutions like ms/apple. > > We will contact Cricket Liu for the detail and > > how common this is. We will update our text accordingly. > > Why not start first by reading his book (which is quite clear) ? > It is a published O'Reilly book and should be readily available. > > According to the book, Microsoft Windows Server automatically > enables Dynamic DNS Update between the Windows clients and > the Windows server in a number of situations. So deployment > of Dynamic DNS UPdate is proportional to deployments of > Microsoft Windows server, which ought to be pretty common > in an enterprise scenario. > [Bing] I searched his book online, but it seems it's not easy to get one in China, hope there could be Chinese version in the future :) We can seek other relevant books/materials. > >> In Section 10, the above draft in part says: > >>> In the LAN, Secure DHCPv6 ([I-D.ietf-dhc-secure-dhcpv6]) or > >>> SeND ([RFC3971], Secure Neighbor Discovery) deployment > >>> may need to validate prefixes. > >> > >> > >> If one thinks that configuring keys for Secure Dynamic > >> DNS Update is difficult or challenging, then it is > >> unavoidable to conclude that neither Secure DHCPv6 > >> nor SEND are actually deployable at present. > >> > >> I think the problems with key management deserve their > >> own subsection in Section 10 -- as a category of "gap" > >> that ought to be addressed. That new subsection ought > >> to note the operational issues with key provisioning > >> and key management for Secure Dynamic DNS Update > >> (at least for non-MS nodes) and equally or more so > >> for Secure DHCPv6 and SEND. One would hope these > >> would not fall into the "unsolvable gap" category, > >> but in any event these gaps do need to be clearly > >> documented. > > > > The key management is a complicated issue. It is worth > > a separated draft. It is relevant. However, we don't > > think it is a renumbering specific issue. We will add > > some new text for it. But we would like to leave it out of scope. > > I do not think that ignoring the issue or declaring it > out-of-scope is a legitimate position to take for this > document. > > IETF rules require that ALL documents must fully address > Security Considerations *within their own document*. > > Ignoring that topic -- or shunting it off to other > documents -- will result in a Last Call objection from me > and possibly others on the very solid technical grounds > that the Security Considerations are known to be deficient. > > >> Similarly, there is a practical operational "gap" in > >> that we have no way to automatically update ACLs during > >> a renumbering event. This also needs to be documented > >> as a gap. > > > > We did list ACL as part of filter, see Section 6.3. > > I did. It is not nearly clear enough. > [Bing] We can add more description. > More text is needed -- and since it is a Security > Consideration it also needs to be referenced in the > Security Considerations section of the document. > > Last, it is very very rude and offensive to take any > private email and post it to any public mailing list > without prior permission of the author -- as you > have done today. > > Yours, > > Ran From wesley.george@twcable.com Tue Dec 20 05:20:42 2011 Return-Path: X-Original-To: renum@ietfa.amsl.com Delivered-To: renum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACDA521F8AF9 for ; Tue, 20 Dec 2011 05:20:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.337 X-Spam-Level: X-Spam-Status: No, score=0.337 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_50=0.001, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qIguT1COywQe for ; Tue, 20 Dec 2011 05:20:42 -0800 (PST) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id B0E9721F8ABD for ; Tue, 20 Dec 2011 05:20:41 -0800 (PST) X-SENDER-IP: 10.136.163.10 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.71,382,1320642000"; d="scan'208,217";a="313274858" Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 20 Dec 2011 08:15:02 -0500 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.26]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Tue, 20 Dec 2011 08:20:37 -0500 From: "George, Wes" To: "renum@ietf.org" Date: Tue, 20 Dec 2011 08:20:37 -0500 Thread-Topic: Adoption call for draft-jiang-6renum-enterprise Thread-Index: Acy/GilkpmS5/K/ES+muIbgtj4tlHw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_DCC302FAA9FE5F4BBA4DCAD4656937791736D9C5A4PRVPEXVS03cor_" MIME-Version: 1.0 Subject: [renum] Adoption call for draft-jiang-6renum-enterprise X-BeenThere: renum@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Renumbering discussion mailing list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 13:20:42 -0000 --_000_DCC302FAA9FE5F4BBA4DCAD4656937791736D9C5A4PRVPEXVS03cor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The authors have published a revision incorporating comments received in Ta= ipei. This starts a call for adoption of this draft as a working group document. http://tools.ietf.org/html/draft-jiang-6renum-enterprise-02 Please reply with statements of support by 10 January. Also, friendly remin= der that we need several substantive reviews of this document. We had sever= al volunteers to do so in Taipei, but more are always better. If you are wi= lling to review, please note that in your statement of support. Thanks, Wes and Tim ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. --_000_DCC302FAA9FE5F4BBA4DCAD4656937791736D9C5A4PRVPEXVS03cor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The authors have published a revision incorporating = comments received in Taipei.

 

This starts a call for adoption of this draft as a w= orking group document.

 

http://tools.ietf.org/htm= l/draft-jiang-6renum-enterprise-02

 

Please reply with statements of support by 10 Januar= y. Also, friendly reminder that we need several substantive reviews of this= document. We had several volunteers to do so in Taipei, but more are alway= s better. If you are willing to review, please note that in your statement of support.

 

Thanks,

 

Wes and Tim=

 


This E-mail and any of its a= ttachments may contain Time Warner Cable proprietary information, which is = privileged, confidential, or subject to copyright belonging to Time Warner = Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you a= re not the intended recipient of this E-mail, you are hereby notified that = any dissemination, distribution, copying, or action taken in relation to th= e contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have receiv= ed this E-mail in error, please notify the sender immediately and permanent= ly delete the original and any copy of this E-mail and any printout.
 --_000_DCC302FAA9FE5F4BBA4DCAD4656937791736D9C5A4PRVPEXVS03cor_-- From wesley.george@twcable.com Tue Dec 20 05:21:38 2011 Return-Path: X-Original-To: renum@ietfa.amsl.com Delivered-To: renum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0C2C21F8B0D for ; Tue, 20 Dec 2011 05:21:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.738 X-Spam-Level: X-Spam-Status: No, score=0.738 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_50=0.001, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZLhcqf30OgnQ for ; Tue, 20 Dec 2011 05:21:37 -0800 (PST) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id D3D5921F8AF9 for ; Tue, 20 Dec 2011 05:21:33 -0800 (PST) X-SENDER-IP: 10.136.163.14 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.71,382,1320642000"; d="scan'208,217";a="313275146" Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 20 Dec 2011 08:15:57 -0500 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.26]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Tue, 20 Dec 2011 08:21:33 -0500 From: "George, Wes" To: "renum@ietf.org" Date: Tue, 20 Dec 2011 08:21:32 -0500 Thread-Topic: Adoption call for draft-liu-6renum-gap-analysis-03 Thread-Index: Acy/GkpQnQv+IW/yQBeDbbasrAWc0Q== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_DCC302FAA9FE5F4BBA4DCAD4656937791736D9C5A8PRVPEXVS03cor_" MIME-Version: 1.0 Subject: [renum] Adoption call for draft-liu-6renum-gap-analysis-03 X-BeenThere: renum@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Renumbering discussion mailing list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 13:21:38 -0000 --_000_DCC302FAA9FE5F4BBA4DCAD4656937791736D9C5A8PRVPEXVS03cor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The authors have published a revision incorporating comments received in Ta= ipei. This starts a call for adoption of this draft as a working group document. http://tools.ietf.org/html/draft-liu-6renum-gap-analysis-03 Please reply with statements of support by 10 January. Also, friendly remin= der that we need several substantive reviews of this document. We had sever= al volunteers to do so in Taipei, but more are always better. If you are wi= lling to review, please note that in your statement of support. Thanks, Wes and Tim ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. --_000_DCC302FAA9FE5F4BBA4DCAD4656937791736D9C5A8PRVPEXVS03cor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The authors have published a revision incorporating = comments received in Taipei.

 

This starts a call for adoption of this draft as a w= orking group document.

 

http://tools.ietf.org/htm= l/draft-liu-6renum-gap-analysis-03

 

Please reply with statements of support by 10 Januar= y. Also, friendly reminder that we need several substantive reviews of this= document. We had several volunteers to do so in Taipei, but more are alway= s better. If you are willing to review, please note that in your statement of support.

 

Thanks,

 

Wes and Tim=


This E-mail and any of its a= ttachments may contain Time Warner Cable proprietary information, which is = privileged, confidential, or subject to copyright belonging to Time Warner = Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you a= re not the intended recipient of this E-mail, you are hereby notified that = any dissemination, distribution, copying, or action taken in relation to th= e contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have receiv= ed this E-mail in error, please notify the sender immediately and permanent= ly delete the original and any copy of this E-mail and any printout.
 --_000_DCC302FAA9FE5F4BBA4DCAD4656937791736D9C5A8PRVPEXVS03cor_-- From lee@asgard.org Thu Dec 29 10:26:52 2011 Return-Path: X-Original-To: renum@ietfa.amsl.com Delivered-To: renum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DDBD21F8B52 for ; Thu, 29 Dec 2011 10:26:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PzLy4LBDrtXM for ; Thu, 29 Dec 2011 10:26:50 -0800 (PST) Received: from omr15.networksolutionsemail.com (omr15.networksolutionsemail.com [205.178.146.65]) by ietfa.amsl.com (Postfix) with ESMTP id 7767721F8B4C for ; Thu, 29 Dec 2011 10:26:50 -0800 (PST) Received: from cm-omr2 (mail.networksolutionsemail.com [205.178.146.50]) by omr15.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id pBTIQlhU028430 for ; Thu, 29 Dec 2011 13:26:49 -0500 Authentication-Results: cm-omr2 smtp.user=lee@asgard.org; auth=pass (LOGIN) X-Authenticated-UID: lee@asgard.org Received: from [204.235.115.163] ([204.235.115.163:50205] helo=HDC00042402) by cm-omr2 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 1B/11-19757-7E0BCFE4; Thu, 29 Dec 2011 13:26:47 -0500 From: "Lee Howard" To: Date: Thu, 29 Dec 2011 13:26:47 -0500 Message-ID: <002401ccc657$6cb8da50$462a8ef0$@org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AczGV2xXXQ6xwx7FSKusHVCSzEftlw== Content-Language: en-us Subject: [renum] review of draft-jiang-6renum-enterprise X-BeenThere: renum@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Renumbering discussion mailing list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2011 18:26:52 -0000 At IETF82, I said I would undertake a review of the documents under discussion. Laboriously detailed notes follow. I have not yet reviewed the other documents, and can't promise that I will be able to do so soon. Lee -- http://tools.ietf.org/html/draft-jiang-6renum-enterprise-02 comments 1. Introduction < currently prefer to Provider Independent > currently prefer to use Provider Independent In addition, PI space may not be available to all enterprises, based on the policy of their Regional Internet Registry (RIR). "It takes the analysis conclusions from [RFC5887]" What conclusions are those? I don't see an analysis or conclusions section. Please enumerate them. 2. Enterprise Network Illustration for Renumbering > Static address assignment is not considered in this version. Why is it not considered? It isn't clear whether you mean "this version of the diagram," or "this version of the document," or "this version of possible renumbering strategies." That needs to be clear. > The > complicated IPv4/IPv6 co-existence scenarios are out of scope. > > This document focuses on the unicast addresses; site-local, link- > local, multicast and anycast addresses are out of scope. I agree with leaving these out of scope, but it would be nice to explain why they're out of scope. And I would move this to the Introduction. This diagram assumes an enterprise has a single hub, which may be multihomed. Is it rare for an enterprise network to have multiple offices, each with local connectivity? Maybe those sites should have two GUA prefixes: one for locally-destined Internet, and one for VPN/private network/Internet access through remote connection. 3.1 Renumbering caused by External Network Factors > The typical scenario is that the DHCPv6 > server in the ISP delegates a new prefix to the enterprise network. Is that typical? Do ISPs typically allocate prefixes to their enterprise customers through DHCPv6? Or is it often done manually? I would definitely think that any BGP multihomed enterprise is not using DHCPv6 to learn its prefix. One could debate whether multihomed enterprises are likely to use PA space, but the goal of the document was to make PA space more usable. Also, enterprised may dual-home to the same ISP. > If the administrators > only want part of the network to have multiple prefixes, the > renumbering process should be carefully managed. I don't understand the implications of this sentence. Can you describe a scenario where an administrator would want that? How would the administrator "carefully manage" that? And does that mean that other cases do not need to be "carefully managed?" Neither 3.1 or 3.2 describes the case of being assigned a new, non-contiguous block of addresses. What if an ISP or enterprise has to renumber into a larger block (e.g., give back a /32 in order to get a /28, or give back a /48 to get a /44). 4.1 Considerations and Best Current Practices during Network Design The prefix delegation paragraph needs more detail. It says both "carefully managed" and "delegated from router to router." As a new reader, these seem to be in opposition. Guidance on good address planning would be helpful here. Note that prefix delegation works in a hub-and-spoke (or centralized, or hierarchical) network, but not as well in a distributed network. > DHCPv6 PD options may also be used between the > enterprise routers and their upstream ISPs. Provide examples, and show how they would be useful. > Fully-Qualified Domain Names (FQDNs) are recommended > to be used to configure network connectivity I agree. I'm not sure rfc5996 is the best example, if only one is going to be used. Use of FQDN for services should imply use (or at least consideration) of DNSSEC; you should note that here or in Security Considerations. I'd like to see more examples of places where FQDN is better than IP address. Identification of database servers, or applications, come to mind. > Service Location Protocol [RFC2608] and multicast DNS with SRV > records for service discovery can reduce the number of places that > IP addresses need to be configured. This may be an excellent recommendation, but it is fairly novel, and requires more examples. mDNS is link-local only, isn't it? That limitation should be noted; it's severely limiting in the enterprise network, which you've already noted is defined as having "multiple internal links." > Manual-configured addresses are not scalable in medium to large > sites, hence are out of scope. True; this should be in the Introduction. > However, some hosts such as servers may need static addresses. Manual-configured addresses/hosts should be avoided as much as possible. I don't know that there's consensus on this point. I also don't know whether discussion of it is appropriate here, or should be in a different document. Why do servers need static addresses? It's not so they're named-you can do that with dDNS. You already pointed out that you can do service discovery with mDNS, SRV, and SLP (maybe within certain limitations). The reasons for static addresses are 1. Monitoring (which could often be done by FQDN), 2. Firewall rules. (yes, dynamic DNS is dependent on having a DNS server that supports dDNS, either your own, or your generous ISP). Advice on how to avoid manual configuration as much as possible would be welcome. ULAs will need to be renumbered for any Internal Network Factor (section 3.2). They are useful only for single-site networks (where all traffic is "local" and/or where a /48 is enough address space). > DHCPv6 can also support host-generated address model This statement is premature, since it is still in draft. Is there running code? > manual on-demand > updating model is considered as a harmful source of problems This statement is too strong. Say, "manual on-demand model does not scale, and increases the chance of errors." > Normally, the dynamic DNS update You say, "Normally," but then propose a different mechanism as BCP. Instead, say, "Dynamic DNS updates can be provided by the DHCPv6 client or by the DHCPv6 server." Then go on to explain how to do each, and make a recommendation if you have one. > In a model including SLAAC This paragraph describes how to do dDNS. It's enough to say this isn't available with SLAAC. This is a significant consideration in the Address Configuration Models section. > exposure to hijacking What kind of threat is this? Man-in-the-middle? Spoofing? Escalation of privilege? I don't understand the threat clearly from this description. > seems there's no real deployment > so far according to the discussion in the IETF meeting. Is it that there's no support among router vendors or OS vendors, or just that administrators aren't turning it on (if the latter, we should recommend it)? Need to be a little more authoritative here, and remember that "the IETF meeting" is vague for a document with a multi-year lifespan. > RA guard [RFC6105] is a light-weight alternative, however, it also hasn't been widely deployed Does RA guard accomplish the same thing as SEND? Is it not deployed by router vendors or OS vendors, just that administrators aren't turning it on (if the latter, we should recommend it)? > For DHCPv6, there are built-in secure mechanisms (like Secure > DHCPv6 [I-D.ietf-dhc-secure-dhcpv6]), and authentication of DHCPv6 > messages [RFC3315]could be utilized. But they are also mechanisms > that haven't been verified by wide real deployment. You recommend DHCPv6 above (for its support of Secure DNS Dynamic Update), but say it doesn't have available security. Is authentication (rfc3315) enough? Here again, a clearer description of threats would allow a clearer evaluation of security mechanisms. > A site or network should also avoid embedding addresses from other > sites or networks in its own configuration data. Amen! < connectivities > connections 4.2 Considerations and Best Current Practices for the Preparation of Renumbering > prefix's lifetime You're talking about ND, and should explicitly say so. > these recommendations are not cost free I understand and agree, but I think your point is, "Since these recommendations would increase traffic and server load, they should only be used in preparation for a renumbering event." > - Reduce the address preferred time or valid time or both. Add considerations for which I should reduce, or when both, and what values I should use. For instance, the valid_time should be less than the shortest possible reconfiguration window. Again, a little extra detail for the network administrator would be handy. > Reduce the DNS configuration lifetime on the hosts. Good idea, but in RAs it's the "Lifetime value of the RDNSS Option." In DHCPv6, I think the lifetime would be the DHCPv6 lease time. What value should it be set to? Two hours? What about reducing the TTL on any DNS records? 4.Considerations and Best Current Practices during Renumbering Operation < service/connectivity will be out for a period till > service/connectivity will be unavailable for a period until The discussion of whether to have a flag day would be better placed in the preparation phase, since it relates to the lifetime settings. > Address deprecation Is this term defined somewhere? > The DNS records should be deprecated as > early as possible, before the addresses themselves. Needs more detail, i.e., DNS TTL should be less than valid_lifetime or DHCPv6 lease time. How do you reduce DNS TTL on dynamic DNS? For DNS records that are not dynamically updated, the sequence should be: 1. Reduce TTL to (e.g.) 3600 2. After adding new addresses, create new DNS records. 3. Wait for an amount of time equal to the previous TTL. 4. Remove old DNS records. By this time, anyone who had the old records with the old TTL has expired, looked up the new records, and has the new TTL (and hopefully, the new address). 5. Wait 3600. This lets the old records expire, after which they shouldn't be cached anywhere. 6. End use of old addresses. To end use before this risks that someone has the old record cached somewhere. It is entirely possible that hosts on the Internet will cache for longer than your TTL, but if you give advice (TTL 3600) and someone ignores it and breaks protocol, you can't fix it. > enforcement messages, either in Router Advertisement messages I'm unfamiliar with RA enforcement messages, please cite. > - DNS record update and DNS configuration on hosts Should this be combined with the "Transition period" paragraph above it? > A notification mechanism may be needed to indicate to the hosts that > a renumbering event of local recursive DNS happens or is going to > take place. >From the context, are "the hosts" the ones doing DNS lookups, or are they the devices being renumbered? Why is a mechanism needed? What kind of mechanism? Is this a gap? > all border routers should > be aware of partial renumbering in order to correctly handle > inbound packets. Internal forwarding tables need to be updated. How should they be made aware? In what way should forwarding tables be updated? Avoid the passive voice. > The egress router connecting to ISP A should be notified How should it be notified? > - Tunnel concentrator renumbering Even if the tunnel concentrator was specified by FQDN in the client configuration, there may be other configuration elements referring to the IP address. Any existing sessions will have to be dropped and re-established to the new address (certainly for IPSec, a new security association is required, and the AH uses the IP address; even for other kinds of tunnels, I don't know of any that could stay up when an endpoint is renumbered). > relevant hosts or routers I'd say "client hosts and routers," to clarify that you don't mean "routers providing paths to the concentrator." Security Considerations Mostly notes as above. > Dynamic DNS update may bring risk of DoS attack to the DNS server. Increased risk of DoS attack, or increased risk of DoS when many hosts are simultaneously renumbered? > along with the update authentication, session filtering/limitation > may also be needed. Block dDNS messages from outside the network. And make sure your server can handle the load if every host sends an update in a 2-hour period. This may also happen after a blackout or other network outage. > co-existence of old and new > prefixes may cause potential risk to the enterprise routing system. What risk? Routing tables that are too large for memory? Too many updates for the CPU to handle? Be specific. > enterprise scenarios may not involve the extreme situation; > this issue needs to be identified in the future. More detail, since I'm not clear on what "this issue" is. Not discussed: Firewall rules Ingress/egress filters/ACLs Updating IGP, BGP Monitoring systems The many cases where configuration parameters require an IP address, not a name. The "preparation phase" here is "complain to the vendor." I like the overall organization: during network design, for preparation of renumbering, and during renumbering operation, gaps. Within the sections, I would have preferred considerations for workstations (SLAAC vs DHCPv6, dDNS), peripherals (ditto plus service discovery), and servers (including DNS, firewalls (and other security systems like IPS and tests), NMS/OSS). I don't know if there are different considerations for Internet-facing servers than for internal-only servers (such as accounting and payroll systems). The framework is the right one, and the considerations are what I would hope for. From brian.e.carpenter@gmail.com Sat Dec 31 11:12:12 2011 Return-Path: X-Original-To: renum@ietfa.amsl.com Delivered-To: renum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 317AC21F8431 for ; Sat, 31 Dec 2011 11:12:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.547 X-Spam-Level: X-Spam-Status: No, score=-103.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P-jn3+z1-jQZ for ; Sat, 31 Dec 2011 11:12:11 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7804D21F8430 for ; Sat, 31 Dec 2011 11:12:11 -0800 (PST) Received: by eekc14 with SMTP id c14so13326104eek.31 for ; Sat, 31 Dec 2011 11:12:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=E2W1ocg/e4/aq98R+O5uQ7CQggF33jM7m8a8YySQEjw=; b=QAXx1rduJ6QQ5MkRmqPMzrwuLHdEVm6H/saqjRB8mWNpIto/Dr3pCKedkfeI8LJWKO kI7QTrRN1J/q43bvGu+ikGFWKl/LBBCObHFj0w/eYfDTGR/RDCJIFeGUmAcSEWY7+02G Vf8DNOfwf8nM+BdA16JhpsVlxN6W0CrrTfC/k= Received: by 10.213.7.130 with SMTP id d2mr5297029ebd.101.1325358730695; Sat, 31 Dec 2011 11:12:10 -0800 (PST) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id q67sm104549639eea.8.2011.12.31.11.12.08 (version=SSLv3 cipher=OTHER); Sat, 31 Dec 2011 11:12:10 -0800 (PST) Message-ID: <4EFF5E80.3040306@gmail.com> Date: Sun, 01 Jan 2012 08:12:00 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Lee Howard References: <002401ccc657$6cb8da50$462a8ef0$@org> In-Reply-To: <002401ccc657$6cb8da50$462a8ef0$@org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: renum@ietf.org Subject: Re: [renum] review of draft-jiang-6renum-enterprise X-BeenThere: renum@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Renumbering discussion mailing list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Dec 2011 19:12:12 -0000 Lee, Thnaks for that very detailed review. We will definitely deal with each point for the next release. > The framework is the right one, and the considerations are what I > would hope for. Could you comment on the WG adoption call that Wes sent? Regards Brian Carpenter